D/FPGAs in an ASIC Core Cell Methodology
Andre DeHon
Original Issue: February, 1995
Last Updated: Sat Apr 8 20:54:28 EDT 1995
This is a quick note on integrating reconfigurable logic arrays ( e.g. DPGA (tn95) (tn114)) in a core ASIC methodology. See [DeH94a] for motivational development on why one would want to do this.
In traditional ASIC methodologies, the customer provides a netlist of gates and macros to the vendor. The vendor, in turn, takes responsibility for all layout issues associated with producing the semi-custom IC. In recent years, desire for efficiency, ease of design, and effective use of larger and larger available silicon area, has motivated vendors to provide large core designs and embedded memories. In the core design scenario, the vendor supplies custom, hard macros for common building blocks, like microprocessor cores, functional units, and bus interfaces. The vendor also provides an assortment of memory sizes and organizations to the customer. Since memories are highly regular and can be parameterized, the vendor typically provides a memory compiler which will synthesize an appropriate memory to the customer's specification. This approach allows the customer to design at the netlist level while giving him more of the benefits of a full custom IC design.
Methods for integrating memories, aggressive, fixed functional units, and random logic into modern ASIC methodologies are now well established. How do blocks of reconfigurable logic fit into ASIC methodologies?
The answer is moderately obvious if we think of arrays of reconfigurable logic much like arrays of memory. Just as vendors have developed specialized memory compilers to produce parameterized layout for various memory configurations, ASIC vendors can provide reconfigurable logic array compilers to produce reconfigurable arrays to the customer's specification. Once specified and generated, the reconfigurable array can then be treated like any other memory or core, hard macro which the customer embeds in his design. Once the array is generated, the compiled array should, in fact, be indistinguishable from core or memory blocks to the vendor's backend placement and routing process.
Today, one primary difference between programmable logic and memory is that memory designs are much more mature and well understood. The function of a memory array is simple and well understood, as are the ways of building them. There is, however, less agreement and certainty about the best way to build a programmable array -- witnessed by the variety of programmable architectures available on the market today. Of course, the other issue which complicates any convergence and may, in part, be responsible for wide variety in commercial, programmable architectures, is that of intellectual property. Reconfigurable arrays are sufficiently new that there are many patents covering their design. Of course, this is not that different from the area of CPU design. There is no clear best architecture for CPUs, and most commercial architectures are protected to varying extents by active patents.
Shown in Figure is the generic, logical view for a
reconfigurable array. The programmable i/o's are shown separate from the
configuration facilities.
The configuration i/o's control the loading of the array's configuration or context. The configuration port can look very much like a memory port. Depending on the design requirements, the port can be anything from a 1-bit serial data port with no address control to a 64-bit wide (or larger) data port with full, random access address control to the internal configuration memories. Wider datapaths support more rapid context loading. Random access to the configured logic allows rapid, incremental changes in the array personality.
The programmable i/o's are inputs to the logic implemented in the reconfigurable array and outputs generated by the array. There need be little direct correspondence between the number of i/o's and the size of the array. In some situations, it will be beneficial for all i/o's to be bidirectional i/o's -- e.g. if the array is being coupled to a common bus on the ASIC. In others, it may be beneficial for all the i/o's to be dedicated inputs and outputs -- e.g. if the programmable array serves as a systolic pipe taking data from one piece of the ASIC, processing it, then putting its output someplace else in the ASIC.
For multicontext ( e.g. DPGA) designs, a context select will specify the active context. As a separate input to the array, the ASIC designer can customize its generation as appropriate to the application. It could, for instance, come from random logic, from decoded CPU signals, from a hardwired sequencer, or even from a programmable output from this or another reconfigurable logic array.
Shown in Figure are three examples of how an embedded,
reconfigurable core might be used.
Processor with Flexible Accelerator -- Here, we see a moderately conventional, microprocessor built out of core and embedded ASIC cells. The reconfigurable array is wired into the processor's register-file data path to serve as an adaptable accelerator.
Configurable Array -- A collection of fixed integer units are embedded in a reconfigurable mesh. This allows the fixed units to be wired up in a post fabrication, application and data specific manner. This might be a fundamental building block in a flexible systolic-array processor.
Security ASIC w/ Flexible I/O -- A core en/decryption engine is embedded along with support memories and a reconfigurable bus interconnect. With this design, a single ASIC can be adapted to a wide range of external bus interconnects, appealing to a large embedded market and allowing the customer to easily target a wide range of busses and to rapidly adapt to emerging bus standards.