Help me choose an fpga (or cpld or whatever else might work)

[cirthix]

I've not done this before, but I have some pretty high requirements:

16 differential output pairs capable of outputting at 165mhz
2 normal outputs (not high speed or differential)

12 differential input pairs capable of inputting 270mhz
2 normal inputs (not high speed or differential)

32mb (only ~28 actually needed) of ram that can be used for cashing these signals for a short period of time (2gb/s in and 2gb/s out max required).

The basic application is to take data coming in on the 12 differential input lines, buffer it for a short period (for syncing reasons) and then split it and send it out on the 16 output pairs.



Very little processing has to be done do this data, it's basically being decoded, buffered, and then encoded again. Other than encoding and decoding, no processing is done.

 

[QuixoticOne]

165MHz is pretty low speed, even 270MHz is not super high if you have limited depth of logic that needs to operate synchronously to that.

What do you mean by differential? What voltage level / signalling standards?
You can do differential TTL just by having Q and /Q as an inverted pair of course.
Or do you mean something like LVDS or whatever?

If you're going to have to use external line drivers / line receivers to handle a given I/O standard then the FPGA itself doesn't really need to be differential though your I/O count is still TINY even with everything fully differential at the I/O pads... 16 pairs = 32 lines, 12 pairs = 24 lines, so basically you're looking at something around 128 pins or less for the whole chip. You almost can't BUY a FPGA that small. Well you can, but the point is that the I/O count isn't a problem, the question is what exact voltage / current / waveform compatibility and impedance do you need the I/Os to have?

As for RAM, that is a lot... more than most devices have... it would be a lot cheaper probably to use an external bit of SRAM or SDRAM/DDR/DDR2 or whatever controlled by the FPGA to act as a buffer rather than buffering the data on 32Mbits of FPGA memory. I'll look at my selector guides for possible devices with that much memory though.

Do you have the ability and resources to design extremely complex printed circuits? Typically the really big memory density FPGAs are in very big BGA packages and are high end parts; you'd be using a tiny fraction of the total pins that might be present on some of these multi-hundred pin BGAs depending on the devices you choose. Using something low end in something more like a TQFP package would probably be a lot cheaper and easier to make the PCB for although you'd need more total devices to do the job (e.g. one or more FPGAs + some external RAMs).

Originally posted by: cirthix
I've not done this before, but I have some pretty high requirements:

16 differential output pairs capable of outputting at 165mhz
2 normal outputs (not high speed or differential)

12 differential input pairs capable of inputting 270mhz
2 normal inputs (not high speed or differential)

32mb (only ~28 actually needed) of ram that can be used for cashing these signals for a short period of time (2gb/s in and 2gb/s out max required).

The basic application is to take data coming in on the 12 differential input lines, buffer it for a short period (for syncing reasons) and then split it and send it out on the 16 output pairs.



Very little processing has to be done do this data, it's basically being decoded, buffered, and then encoded again. Other than encoding and decoding, no processing is done.

 

[QuixoticOne]

I looked at some of the more recent devices, and I can't bring myself to think that any of them would be appropriate for a monolithic implementation of what you're suggesting. They have generally too little or just barely enough memory even in the highest end devices -- ones which are extraordinarily expensive to design with and complex to design PCBs for.

Except for the memory capacity, though, most any mid-range / low cost FPGA might well serve your I/O and bandwidth needs depending on what exactly those are.

The correct solution IMHO is to interface a small number of low cost FPGAs to a small number of SRAM or DRAM devices for the memory and just program the FPGAs to use the external RAM as a FIFO, something which is quite commonly done with FPGAs.

AFAICT that would be a lot easier to design and probably a lot less expensive / difficult to implement in terms of PCB engineering and FPGA / RAM device cost than trying to use one or two of the biggest capacity commercially available FPGA units so that you didn't have to use external RAMs.

 

[QuixoticOne]

Check out parts similar to the following:


Altera CYCLONE III
EP3C16

Xilinx SPARTAN 3 / 3E / ...
XC3S250E
XC3S200A
XC3S200AN
XC3S250E
XC3S200

Lattice ECP and similar
ECP2-12

Without knowing much / enough about what you're trying to do to make a very detailed estimation, I'd suggest looking at partitioning the design between two FPGAs each in something like a PQFP 208 / PQFP 240 type of package. You could possibly do one smaller PQFP144 and one larger PQFP208 device to help lower cost, though using two of the same devices often has inventory / ordering / assembly related cost advantages, so it may be better just to go with two of the same.

The reason for the PQFP would strictly be ease of PCB layout and cost of the PCB; if laying out & assembling multi-hundred ball fine pitch BGA is no problem for you, just select a larger I/O count BGA device and use one FPGA to handle all the logic needs.

In addition to the FPGAs use something like 16 or 32 bit wide DDR/DDR2 RAMS for your 32 megabits of buffering. I have no idea how complex your access pattern would be, but assuming you just need a FIFO then that should be pretty straightforward. So you'll be 1M-2M deep in word addresses for 32Mbits memory capacity if you're 32 bits wide or 16 bits wide respectively.

There are certainly faster and more capable chips out there, these represent some of the lower device cost options with respect to volume uses and probably / sometimes development kits & tools depending on your in house EDA capacities and distributor / vendor relationships et. al.
If your design / production budget is higher then it may be easier to just go with some of the higher end parts and be able to take better advantage of some of the (IP) / tools / design benefits that go along with those families.

For minimum cost in low volumes you could probably find out what devices / development boards are the most inexpensively available and then perhaps struggle a bit to find out how to partition the design into smaller or older generation parts or whatever. Your overall complexity may not be so high that you couldn't do it with pretty basic parts of most any nature; the best trade-offs depend on your circumstances and design details.

 

[cirthix]

Thanks for the advice. I've decided to drop a few features to greatly drop the complexity of the project. ygpm .