Emerging Trends in PLD Tools

Process advances and new design methodologies push programmable logic tool vendors to extend tools to accommodate multiple processors, widely dispersed workgroups, and Web support.

by Martin S. Won and Balaji Thirumalai

In the coming months, digital systems designers will find themselves facing programmable logic device (PLD) designs in the million and multi-million gate (MMG) range. While ASIC designers are already dealing with these densities, programmable logic users are just starting to encounter this situation. In both cases, device densities are increasing rapidly beyond the scope of existing tools. As a result, designers and EDA vendors alike are developing dramatically different EDA methods and technologies to accommodate them. A workgroup computing environment spanning multiple campuses will replace the traditional methodology of a single designer owning a project. At that point, revision control similar to that found in large-scale software efforts will be vital to ensure design integrity. In addition to utilizing multiple designers, such projects will also require greater computational resources such as multiprocessor support and distributed computing capability--and the design tools will need provisions for marshalling the resources.

Another issue arises from the common practice of utilizing tools from multiple vendors to take advantage of their differing feature strengths during the various stages of the design flow. Tool manufacturers have recognized that this trend will intensify and are adjusting their tools to accommodate greater compatibility and integration beyond the simple sharing of compatible file formats. Designers also currently benefit from the ability to write scripts to configure the operation of their tools; tomorrow's tools will be even more open, enabling users to control every aspect of tool operation.

If the experience of ASIC designers is any indication, the era of MMG programmable logic designs will find verification occupying the largest part of the design cycle. As design complexities increase, other techniques and tools will have to supplement traditional methods of design verification such as simulation; the full range of real-world stimulus for designs in this realm can't be simulated within a reasonable amount of time. In addition, the sheer size of the designs will demand that new tools be created to verify the internal operation of the programmed device.

Finally, tool providers are taking advantage of the Web. The Web's ability to provide access to the latest information, including documentation, technical support, and automated updates, will become an integral part of emerging design tools.

Workgroup computing

More often than not, design teams--rather than a single individual engineer--handle MMG designs. In order to accommodate these teams, EDA tools can incorporate a number of features to facilitate and manage the process, including source-control capabilities and a design database scheme that allows team members to work interdependently. Many EDA users employ different systems of source control, including RCS, SCCS, and PVCS. Others may use a proprietary scheme or, in some cases, none at all. To gain wide acceptance by the users of the various systems, future tools should support the common schemes and allow configuration to accommodate nonstandard systems.

On the other hand, allowing multiple users to access the same design is a more difficult proposition. Any multi-user system must account for the fact that individual designers or teams will rely on the work of other team members and vice versa. Multiple versions of the same design might exist at any given time, and users should also be allowed to pursue their own compilations, either of portions of the design or of the entire design. At Altera, we have developed a model to meet this need. Similar to capabilities found in software compilers where the development tool manages a single master version of the design, Quartus requires the design tool to act as a design administrator. In this scheme, the master version of the design resides in a central network location and parts of it are "loaned out" by the development tool to the various members of the team as needed. All team members may read any part of the master design file as needed, but only one team member at a time possesses write permission for a particular portion of the design (see Figure 1). If the user has compiled a portion of the design to be uploaded to the design administrator, the tool uploads all ancillary files resulting from the compile as well, allowing later compilations to take advantage of any already completed design processing.

Some teams may want to allow individual members to compile their own versions of the master design, so the tool enables them to keep any version of the master design on their personal workstations. When the team member reports back to the design administrator, the administrator informs the designer of any changes that have taken place in the master design since the last visit and offers the option of downloading those changes to the personal workstation. In this fashion, an individual team member has the flexibility to adopt new design parts as desired.

Along parallel lines

Parallel computing offers great opportunity to accelerate design compilation tasks in both PLD and ASIC methodologies. Any time a lengthy compute-intensive process can be divided into a series of smaller tasks, opportunities are available. Parallel computing models exist for many types of processes, but the tasks associated with compiling PLD or ASIC designs offer radical differences. Significant research has explored the use of simple processor arrays to solve problems, but the solution more typically involves running a series of small jobs that require minimal data transfer and intelligence among the tasks. Optimization for PLD and ASIC design acceleration requires extensive data-transfer bandwidth for reading in information before crunching compilation data. This process requires a more coarse-grained implementation than the typical launching of isolated design tasks.

Figure 1 - Keeping the workgroup satisfied
Tomorrow's PLD tools should offer careful design database management as well as source control provisions, allowing design teams to specify read and write privileges and team members to work individually on various portions of a design.

The first order of consideration involves examining the entire compilation process for bottlenecks to determine the candidate tasks that will most benefit from augmented processing. According to our studies, as much as 70 percent of the PLD design processing cycle is allocated to "fitting" the device into a target architecture, providing an obvious focus for future efforts. One of the factors that influences the application of parallel computing to PLD design processing is the architecture of the PLD itself. For example, using a PLD that is architected hierarchically (composed of several independent structures connected at one or more higher levels) eases the burden of identifying individual compilation tasks. The processor can then distribute the tasks in parallel among the available computing resources. As device densities increase, the hierarchical structure must also increase. Real-world testing confirms that parallel computing combined with extended hierarchies can indeed decrease compilation times (see Figure 2). For example, preliminary work on a structure targeting parallel processing of rows demonstrates an average of 10 percent compilation time reduction with each additional CPU--including as much as a 50-percent compilation time reduction with a 10-processor network.

Additional opportunities for parallelism will exist any time compute-intensive functions can be split; attractive areas for further research include netlist extraction, database building, hierarchical synthesis, and multipart partitioning. Obvious difficulties arise, however, because the tasks ideally suited for parallel computing can't be implemented until serial tasks such as netlist extraction and logic synthesis are completed. Therefore, securing additional parallel CPU resources must occur after the initial task begins. In a typical load-sharing FIFO queue, CPUs for parallel processing might not be readily available when needed.

Ideally, the object-stored database should enable heterogeneous processing over mixed Unix/PC networks to take advantage of diverse design environments. Hooks to existing tools, such as LSF, provide one option for users to set up this environment. A GUI enabling CPU selection and highlighting CPU loading (based on past performance) can add further value. Intelligent CPU selection based on system memory and CPU speed can also help to optimize results.

Another option in parallel processing is to launch a series of independent compilation processes, each using a different seed point on a unique CPU. The method does indeed find different permutations of the design (such as variations in speed and resource utilization), but it isn't likely to accelerate the process. In fact, this strategy may take longer to arrive at the same result than distributing a single task among several different processors.

Open up and verify

One of the pervasive characteristics of the modern EDA environment revolves around users that typically employ a number of different tools provided by a variety of vendors. The tools require various degrees of user interaction to coax them to interoperate and to achieve optimal results; a user must often take responsibility for identifying the output of one tool and conveying it effectively to the next tool. Many EDA tools are scriptable to some degree, or allow command-line operations to provide easier automation and customization of these and other processes. Such functionality marks a step in the right direction, but doesn't achieve seamless interaction between tools.

Figure 2 - Reduced processing time
Multiple processors reduce PLD design processing time. In a study that fit designs into row-based devices, each additional processor reduced the fitting time by about 10 percent.

Tool vendors could achieve a more complete solution by exposing the application programming interface (API) of their tools to both users and other tool vendors, thus allowing them to code their own functionality. Given this "open API," users could then automate tool operations, such as the transfer of data from one tool to another. For maximum convenience, an open API would allow the initiation of tool processes from within other tools, enabling users to work in the environment of their choice. Ideally, an EDA tool's open API would also allow it to interact with non-EDA tools--such as productivity tools--that nevertheless form a significant part of the user's work environment. A user could then automatically record the results of tool operations in a spreadsheet, word processor, or project scheduler.

Verification of multi-million gate designs will require new tools and methods to address both their increased size and complexity as well as the changing nature of high-density PLD designs and devices. Additional verification options will accompany every part of the design cycle. For example, in the design entry and simulation portions of the design process, improved integration between PLD development tools and synthesis and simulation tools will enable users to check timing and utilization more easily--and to automate procedures that iterate design compilations within various settings. The increasing use of intellectual property (IP) will expand the number of designs that include material from several sources, requiring another level of sophistication in the verification process. To alleviate this complexity, vendors of IP will cooperate among themselves and with PLD vendors to coordinate and verify their offerings. Of the industry "standards" for IP verification in development (VSIA On-Chip Bus and GEPDISC debug interface, for example), none are mature and it's impossible to predict which if any the design engineering community will eventually embrace.

Finally, in the hardware verification stage, traditional probing device methods on the board will prove cumbersome as designers deal with the decreasing dimensions and higher pin count packages found in products such as BGAs. New methods of observing device operation will emerge to reduce or eliminate the need, as well as to decrease the amount of board space devoted to probe test points.

Typical of a development in this area, Altera's Signaltap tool aims at improving verification and allows a designer to inspect a PLD's internal signals while in operation. Users can view the signals as waveforms on a workstation through a download cable linked to the PC board, or by way of traditional board analysis equipment. Similar to a logic analyzer, users can set the initialization, triggering (internal or external), and display conditions, as well as access any internal signal. The analysis parameters are compiled into an embedded logic analyzer and then programmed into the device along with the rest of the design information.

These embeddable analyzers can be applied to any portion of the design, including other cores--for instance, microprocessors as well as PCI and DSP functions placed inside the chip. Users can activate the analyzers across multiple instances, debugging the interface between IP blocks and between the IP blocks and their own value-added portion of the design. Pattern recognition capabilities allow for the definition of complex triggering conditions, including duration and repetition qualifications. Complex events can be recognized by linking patterns with if/then/else and store commands. The Signaltap megafunctions operate at the speed of the device and occupy a relatively small amount of device real estate. In one instance, an implementation monitored 128 different signals and required less than 7 percent of the logic in an Apex 20K400 device. When device verification is complete, the megafunction can be removed from the design or left in to provide a debug tool for the system integrator.

Webbed tools

Not surprisingly, the Internet and related technologies are finding their way into software tools. Within the context of EDA tools and the demanding development cycles that occasion their use, the Web provides an excellent way to offer crucial round-the-clock technical support to a design team as needed. A well-tailored Web site should keep users updated with any changes made to the software or products; users wouldn't need to wait until the next software release to fix problems or obtain a software patch or new device information.

Today, however, most EDA tools ship with only a finite amount of on-line help information. The shipped content generally doesn't reflect changes made to the software until the next release, which limits the usefulness of the on-line help shipped with a tool. Ideally, the EDA tool should be Internet-aware, with some intelligent capability to connect to the tool vendor for additional technical support information. The intelligence would facilitate direct access to technical collateral such as application notes and product literature. A further possible enhancement would provide links to a database of solutions and a problem-tracking system. While running the software, users could submit service requests directly to the factory by way of the Internet, the tool automatically preparing the design files and user configuration for transfer. The feature would ensure that the support staff working on the problem could accurately duplicate the design environment at their site. During the issue resolution, a user could track the progress of the service request. Other web extensions would facilitate the business side of the vendor-customer relationship; users might register their software and obtain licenses directly from within the EDA tool. Such a system effectively integrates the EDA vendor into the users' design teams, providing valuable and timely support to the designers.

Users must ultimately control whatever information they access or send to the factory. The tool should let the users configure how often the tool accesses the technical support information and whether or not it can send design information over the Internet. EDA vendors must also ensure privacy and security for both their customers and themselves. The vendors need to guarantee a secure connection to its databases, given the sensitive nature of the information being transmitted out to the design teams and back. Fortunately, existing security precautions indicate that such transactions will be at least as safe as today's Internet commerce transactions--in other words, a reasonable amount of caution is warranted.

As million-gate designs become more prevalent in PLDs as well as in ASIC technology, new tools that embrace the latest advances in computing hardware and software are necessary to realize the products' full potential. True productivity improvements will require software tools that take full advantage of the strength of the target architecture; vendors must design the software to act in concert with the silicon. Extensive opportunities do exist to improve productivity by utilizing parallel computing, workgroup computing, improved verification, and the Web--but the tools must support these changing design methodologies. Design tool development, particularly in the PLD realm, must then accelerate even further to keep up with the increasing device density and capability.