NOTE: THIS DESIGN COMES WITHOUT ANY WARRANTY. IT MAY FRY YOUR HARDWARE. PLEASE READ MORE BELOW.
MPGA project with mailing lists and web forums
This is an open source design for an FPGA to be implemented on an FPGA; a 'meta-FPGA' (hence the name). If you wonder whether something like that makes any sense, then chances are that it won't be useful to you. However, this MPGA has a few nice properties that 'real' FPGAs lack. It has open programming specs, and a bitstream format that's amazingly easy to edit. This means that you aren't bound by limitations of vendor tools. (If you wonder what those limitations are, don't worry, be happy;). The open specs and design can also be especially attractive for open source tool development. Another notable feature is that you can (re)program an MPGA as fast as you like (and are willing to spend bandwidth on). This is rather nice for reconfigurable computing or evolutionary design experiments.
The density of the current MPGA is actually fairly high: one MPGA CLB is implemented using one Virtex CLB. Of course, the MPGA CLB can't offer all the functionality of a Virtex CLB, but does offer FFs, LUTs, and (independent) global routing. Local routing is probably the weakest part of the current design, a fair percentage of CLBs will be needed for local routing through the cell. Also, I'm unsure how well automatic routers will be able to deal with the limited routing structure. And don't expect MPGA designs to achieve particularly high clock frequencies: there will be many levels of logic in most designs, because routing switches are implemented with LUTs.
The user-visible CLB logic is shown in figure 1. The LUTs and selector are programmable; the FFs are simple positive edge triggered D flip-flops. The F output is used for local connections, the G output for global interconnect.
Figure 1: CLB user logic.
Note that the interconnect structure as described below actually depends on configuration parameters, and will probably change in the future.
The A LUT inputs connect to the F CLB outputs of the local cluster (a cluster is a section of 2x2 CLBs). Three of the B LUT inputs connect to F outputs from adjacent clusters; one connects to the local G output. The C LUT connects to G outputs a distance of 6 CLBs away, in four directions. This way, the G network provides for independent global (long distance) routing.
Local routing details are shown in figure 2. Each tile of the grid represents one CLB; cluster borders are emphasized. The B LUT connections for center cluster CLBs are indicated with symbols showing to which CLB in the center cluster they belong.
Figure 2: B LUT local routing.
The ASCII bitstream format, see figure 3, shows the interconnect structure in full detail. LUTs are represented as Karnaugh maps, FFs as ''. The top left CLB of each cluster is marked with an MPGA logo. Two clusters are shown in the figure.
Figure 3: ASCII bitstream format.
The MPGA project is currently in a larval stage. The code is a mess, and many important features are lacking (see TODO). Right now it is more a proof of concept than something fit for use. However, it works as far as tested, there's a parametrized MPGA core generator, there's support for simulation and downloading to hardware, there is even a tiny example design. At this point I would like to get some feedback, so please have a look. You're also welcome to improve things as you see fit (as long as you give changes back). You can mail me at firstname.lastname@example.org (no, don't remove the 'remove' in there;).
Please be warned that YOU CAN BLOW UP YOUR EXPENSIVE HARDWARE if you aren't careful with the MPGA as it is now. It's all too easy to download a design with (unintended) combinatorial loops in it, there is no DRC, no warning. Worse, during the download process itself, there can be transient conditions with combinatorial feedback in an otherwise clean design. These 'transient' conditions may last longer than you'd like, with the current unfinished controller and download software (they were designed with safe operation in mind but not quite there yet). Resulting oscillations may cause widespread high frequency switching and this may draw more power than your hardware was designed to handle. So without proper precautions you might fry your expensive FPGAs, power supplies, or PCBs. It's probably best to use a power supply that limits current to safe levels, or to keep the MPGA core and connected logic small enough to be safe. The default core configuration in the source is quite small, you may want to keep it that way for now. Anyway, be careful.
See HOWTO for details on how to configure, build and use the MPGA. Core generation, simulation, downloading and testing are done in a Linux environment, synthesis and P&R are done with Xilinx Foundation tools. The current MPGA is written in C and Verilog, targets Virtex and alikes, and is set up to use the BED-SPARTAN2+ board from BurchED (the nice new models may work too).
This development is funded in part by STW / NWO and Delft University in the Netherlands, as part of the MOVE project. Although he is probably blissfully unaware of this little project, I would like to thank Stephen Williams for Icarus Verilog. Special thanks for interesting discussions and suggestions go to Graham Seaman of Open Collector fame. Thanks to Rogier Wolff for sharing his Linux expertise. And many thanks to Henk Corporaal for supporting this crazy little project.
This work is dedicated to Jean Pierre Veen, our benevolent Program Officer at STW, who died shortly before the initial MPGA release.
The MPGA is licensed under the Design Science License. The DSL is a generalised GPL, covering more than just software; see http://dsl.org/copyleft/ for more information.
Copyright © 2001 Reinoud Lamberts
This information may be copied, distributed and/or modified under certain conditions, but it comes WITHOUT ANY WARRANTY; see the Design Science License for more details.
Any trademarks are the property of their respective owners.