FPGA

michael at michaelshiloh.com michael at michaelshiloh.com
Wed Dec 6 18:47:41 CET 2006


On 12/5/06, Markus Stehr <bastetfurry at ircnet.de> wrote:

>  What do you think about giving the Neo1973 a FPGA?

I was thinking more about this last night. My first reaction was "great", but
as someone else posted, what do you get for the increased cost, besides speed?

Answer: the high speed allows you to emulate hardware. Some excellent
suggestions here (software radio, etc.) all take advantage of this ability to
emulate hardware. My Big Idea (IMHO) is that it allows us (developers and FIC)
to experiment with alternative hardware, to develop applications using that
hardware, and to help FIC decide what hardware to add (or remove) in future
versions.

We've had strong discussions over what hardware we'd like to see in the
device, with strong arguments on both sides, and all make good points. For
example, awhile ago someone wanted another serial port (I forget for what:
IrDA?).  The SOC has only two serial ports, and both are in use. Would we give
up one of those for IrDA? No. Solution: implent a third serial port in the
FPGA.

Reconfigurable hardware is limited without specific peripherals; e.g.  the
extra serial port by itself doesn't provide IrDA support: we still need to add
the IR diode and sensor.  So, I suggest that a good portion of the IO pins of
the FPGA be brought to an external connector, to which we can connect
periperhals.

This is probably of limited use to consumers: few consumers will consider an
external IrDA "dongle" to be true IrDA support. However, for us experimenters
and developers, it is incredibly powerful. And, it allows us to develop
applications that would use these periperhals, so that our community and FIC
can make intelligent design decisions about what hardware should be in future
versions.

Another feature the FPGA provides is the ability to route to the connector
signals from inside the device, at hardware speeds. Someone mentioned wishing
for some solder tabs on the board, to access important signals. The FPGA and
the connector would be a safer way to do that.

The FPGA and the undedicated pins on the connector make this device very
useful for OEMs who create peripherals for specific niche markets. FIC does
sell to OEMs, right?

   For example, perhaps police cars have some special hardware in the car that
   needs to talk to a smart phone. Implement the appropriate interface in the
   FPGA, create a docking station for police cars with the right connectors,
   and you've got a near-custom device that did not require a custom design.
   (Note: I know nothing about police car electronics. It's just a hypothetical
   example.)

   Another example: Portable Point-Of-Sales terminals or bar code scanners used
   in retail stores. Again, implement the appropriate hardware interface in the
   FPGA, add appropriate docking station or cable, and the product is ready.

   In both examples time-to-market and development costs are slashed. OEMs can
   get into, or test, niche markets for a fraction of the cost. Even if they
   later chose to redesign the hardware, this provides a rapid prototype and
   proof of concept, useful in making the sales pitch, and provides their
   programmers a platform on which to develop the software long before the
   final hardware is ready, and as we all know software takes a long time.

What hardware peripherals would you add, if you had this options?

   USB 2.0?
   That second SIM card?
   Other FLASH card interfaces?
   I2C, SPI, One-Wire?
   VGA out (although I suspect it would require too big an FPGA)?
   Bluetooth?
   Game device interfaces?

I welcome your feedback.

Michael




More information about the community mailing list