Dwight Hill

An industrial view of electronic design automation

The automation of the design of electronic systems and circuits [electronic design automation (EDA)] has a history of strong innovation. The EDA business has profoundly influenced the integrated circuit (IC) business and vice-versa. This paper reviews the technologies, algorithms, and methodologies that have been used in EDA tools and the business impact of these technologies. In particular, we focus on four areas that have been key in defining the design methodologies over time: physical design, simulation/verification, synthesis, and test. We then look briefly into the future. Design will evolve toward more software programmability or some other kind of field configurability like field programmable gate arrays (FPGAs). We discuss the kinds of tool sets needed to support design in this environment.

Architectural and physical design challenges for one-million gate FPGAs and beyond

Process technology advances tell us that the one-million gate Field-Programmable Gate Array (FPGA) will soon be here, and larger devices shortly after that. We feel that current architectures will not estend directly to this scale because: they do not handle routing delays effectively; they require excessive compile/place/route times; and because they do not exploit new opportunities are presented by the increase in available transistors and wiring. In this paper we describe several challenges that will need to be solved for these large-scale FPGAs to realize their full potential.

Guest editors' introduction: RTL to GDSII - from foilware to standard practice

CHIP IMPLEMENTATION, from a RTL description in a language such as Verilog or VHDL to tapeout in the form of mask tooling data, is the process by which product concepts can become high-value realities. Designers often view chip implementation as comprising logic synthesis , placement, and routing (SP&R), which are all classic point tool arenas. Commercial logic synthesis tools have been in wide use for more than a decade, and practical place-and-route systems date back more than 30 years. Complemented by analysis point tools (for parasitic extraction, crosstalk and delay calculation, and static timing-noise-power verification), SP&R implementation tools have allowed design teams to devise flows that spiral in from RTL timing estimation and global interconnect planning to a final detailed layout. This spiraling entails successive refinement: Logic moves from functional descriptions to optimized circuits, spatial embedding of devices and interconnects become codified, and estimations of parasitics prove ever-greater accuracy. Most of the work in RTL to GDSII has burgeoned in industry, not academia. This is in part a result of the complicated and somewhat messy nature of the problem. To demonstrate results, a flow needs competitive technology in several areas, which involves more software than a typical graduate student group can manage and maintain. Much of the complication stems from the flows multiple representations. The unified implementation flow is sometimes called physical synthesis, or more often, RTL to GDSII. But both of these names oversimplify the actual process. It is not just RTL logic that enters the flow and GDSII that comes out. It is true that in a typical flow, the system accepts a collection of RTL files for entry. But to begin synthesis, the tool typically needs many libraries that describe available cells and underlying technology constraints. For example, timing libraries describe the delay properties of the cells. These libraries usually begin in textual DCL (delay calculation language) or .lib formats, but are often compiled into binary representations that are more convenient for the tools. Physical libraries describe the geometry of individual logic cells, as well as I/O buffers and locations. The physical models of the logic cells can originate in GDSII, but GDSII itself is insufficient to process them. Because GDSII does not define the properties of its layers , other files are necessary to interpret the GDSII geometry. Other technology files describe the available layers, the routing and placement rules, and the site array types (even …

Three decades of HDLs. II. Conlan through Verilog

For pt.1 see ibid., June 1992. Current hardware description languages (HDLs) benefit from the efforts of designers of VHDLs in the mid-1970s through the late 1980s. The developers of four HDLs discuss their motivations and their views of how their work relates to the present very-high-speed integrated circuit HDLs (VHDLs). The languages discussed are Conlan, ADLIB/SABLE, Zeus, and Verilog. >