[sdiy] FracRak digital module?

[Eric Brombaugh]

On 04/22/2011 10:08 AM, Scott Gravenhorst wrote:
> "Barry Klein"<Barry.L.Klein at wdc.com>  wrote:
>> Dave Jones on the AmpHour podcast brought up a very good point:
>> Why aren't there fpga's with a small pin count?
>
> I'm going to make a wild guess since I'm not a market analyst...
>
> Perhaps because of the amount of logic inside, it may have seemed likely that the FPGA
> would often be a do-it-all device, so many applications might need lots of I/O to
> connect to it's peripherals.  This differs from a CPU based application that is forced
> to share data busses among several peripherals which can limit the total bandwidth that
> is actually used.  With large numbers of pins, less buss sharing is required and buss
> protocols don't all have to adhere to the same rules which eases design constraints.  I
> would think that the FPGA mfrs have researched this issue and came up with the many pins
> approach out of a desire to sell as many as possible.

I think Scott has the answer - market analysis shows that most 'sockets' 
for FPGAs are in designs which need a lot of I/O.

Another consideration - I've made some DIY boards using FPGAs with the 
minimum pincount package which is a 100pin VQFP in Xilinx. The actual 
I/O pins on this are actually limited to around 60% of the total pins 
due to the overhead/support required: multiple power supplies for I/O, 
core & auxiliary, lots of ground pins to improve signal integrity, 
configuration and debug pins. Given the number of support pins needed 
for even a small FPGA, if you tried to squeeze it down to a 28-pin 
package you'd be left with only a dozen or so pins available for general 
I/O.

FPGA vendors would have to make a fundamental shift in the way they 
think about their products to get around this. Devote less I/O to the 
configuration process - possibly limit themselves to a simple serial 
port (2 or 3 pins) for configuration and debug. Use older process nodes 
that require simpler power supplies, or move more of the supply 
circuitry on-die. Use Flash memory on-die to store the configuration 
bitstream so fast parallel configuration interfaces aren't needed. There 
are a few FPGA startups that have tried this route but they don't seem 
to garner a large enough niche to survive against the established vendors.

Eric