fpga4fun.com

How viable would it be to try and use a Pluto, with an external 256K x 8 or 256K x 16 SRAM chip, to create a homebrew quasi-VGA card capable of pulling off at least 320 x 480 with 15, 16, or 24-bit color?

Let's start with the basics... if the Pluto had to do little more than generate the sync pulses, pull 2 or 3 bytes per pixel from the SRAM, and throw them at an external RAMDAC (or resistor chain?) with the proper timings to look like reasonable & stable 640 x 480 60hz VGA... is it up to the task? Or is that particular board too slow, or otherwise just not powerful enough?

Similarly, if the homebrew VGA project were to fall through, can the Pluto at least drive just about any random recent-vintage "controllerless" graphics LCD panel from the surplus pile at AllAmerican, MPJA, Electronics Goldmine, etc?

The FPGA by itself can certainly drive controllerless LCDs.

The hard part with the SRAM is how to connect it with decent signal integrity. Just wiring it up with flying leads would not work very fast, so you might have to design a daughterboard.

Well, what I had in mind was treating the Pluto like a SMT chip on a Schmartboard... soldering male headers to the Pluto, and putting everything else on a circuit board with female receptacles for the Pluto to plug into.

Are there ready-to-use libraries somewhere for things that are presumably common, like interfacing with a SRAM chip or acting like a timer? By the same token, is it significantly harder to interface with something like a DIMM, or with the FPGA is it little more than soldering a SDRAM DIMM socket to the board instead of a 40-pin DIP socket and using a different library that someone else wrote instead? (I know that at the bare metal level there's a world of differece between SRAM and DRAM, but I'm not sure just how much the FPGA can smooth over those differences and make them both almost as easy to use). From what I understand, modern SDRAM (and especially DDR/DDR2) is almost as fast as SRAM in situations where you're mainly reading and writing long chains of sequential bytes, and only fall flat on their face performance-wise if you try to write a single byte/word/longword at a time and have to reload the address for each read/write.

The Pluto bottom header can carry fast signals (like Flashy at 100MHz), while the side headers are not designed for high-speed interfaces. For a RAM, you need quite a few signals so you need both headers. Keep the connections short to run out of signal integrity problems, and use the signals at the bottom of the board in priority, there are more GND signals distributed among the IOs, which helps for signal integrity.

There is no library. SRAM and timer functions are easy to write. DRAM is harder, although at some level of abstraction, they can become equivalent as you mention. But it's up to you to build the abstraction stack.

What is it that makes the bottom header "fast", but the side headers "slow", and what do you actually consider to be "slow" (everything I've done up to this point has been with 8MHz or slower AVRs, so to me, "fast" means "8+Mhz" & I don't really have much of a reference point for FPGAs )

One thing I just noticed... the Pluto doesn't have any onboard flash, and has to be externally reprogrammed each time it's powered up, right? If I wanted to use an Atmel AVR to do the uploading, how much flash would I need to hold the biggest chunk of data that could conceivably need to be uploaded into the Pluto's FPGA? Also, does the Pluto's uart support only standard PC/16550a baudrates (maxing out around 115k), or can it also do nonstandard baudrates as well (~1mbit/sec is popular for rs232-like AVR to AVR communication)?

I read somewhere that the Pluto 2 doesn't have a JTAG header, but one can be soldered "to the bottom". Does "bottom" mean "pad or hole somewhere on the circuit board", or do you literally mean "solder wires the diameter of a human hair directly onto the TQFP pins themselves?"

Also... can an Atmel Dragon be used for JTAG programming a Pluto 2 or Pluto 3? Or would it be like trying to use a random PCI videocard in a Macintosh (it would mechanically fit, and be electronically compatible, but Altera's own software won't have any clue what to do with it)?

1. The top and bottom headers are the same, but there are more grounds pins on the bottom header. More ground pins means better signal integrity. Better signal integrity means faster signals possible.

2. Yes, you need to reconfigure the FPGA at each power up. You need 20KB of memory (or less if you apply any simple compression, the files are full of 0s).

3. The UART is made inside the FPGA, which means it can do anything. You need 115Kbaud for the configuration, but once configured, you can go higher (limited by the Pluto electronics, not by the FPGA itself). 1Mbits seems reasonable, although I haven't tried it!

4. Pluto-II's JTAG is on little pads, so it's not too hard to solder, certainly not as hard as soldering right on the TQFP pins!

5. JTAG programming is more involved than standard programming (i.e. through RS232 on the Pluto line of boards), but that's feasible. See the JTAG project on fpga4fun for a starting point.