Complex Designs Demand Greater Attention to Data Management

Complex designs generate huge amounts of data. A data-centric design methodology addresses the data management challenge by employing a design-centric rather than a tool-centric methodology.

by Bob Potock and Dave Brady

In design, data is king--no data, no design. Design engineers using traditional methodologies have relied heavily on a tool-centric approach to their tasks--a linear process whereby the designer opens one tool after another, as needed, in working through the design flow. For example, a design engineer first launches a simulation tool and then loads the data , arguably a straightforward operation assuming that the relevant data resides in a single HDL file. Should, however, the designer need to simulate a schematic that also includes a state machine and HDL text along with gate complexities, the process can quickly derail the point tool train. In that case, prior to simulation the designers must take several manual data management steps, including HDL code generation from the state machine and schematic as well as the updates to various data files.

The data-centric management tool extracts the desired hierarchical branch and prepares the necessary data for simulation based on the new root of the design.

To address these problems, design engineers can now employ a new data-centric methodology. With this approach, the designer selects a design element and launches the proper operation from a list presented by the data manager. If the design element were as complex as the example above, the data-centric management tool would launch a simulation tool automatically, immediately after generating the proper simulation files. The data-centric function would generate and load all HDL files, stimulus, libraries, and SDF files.

Currently, simulating a hierarchical block within the schematic using tool-centric methodologies requires a large number of manual operations, including copying, pasting, and editing. The data-centric management tool instead extracts the desired hierarchical branch and prepares the necessary data for simulation based on the new root of the design. Thus, data-centric strategies facilitate processes for the design engineer.

By placing a layer of abstraction between the designer and the point tools, data-centric operations offer a basis for successful management of the ever-increasing complexities of system, ASIC, and FPGA design. Although point tools powerfully execute a specific set of operations, the design engineer must first provide the necessary input data. Therefore, as the design complexity increases, the effort behind the data input generation quickly becomes a burdensome clerical challenge. The current tool-centric design process falls short of meeting the needs of today's complex FPGA design; the data-centric tools offer a productivity boost to the design process.

Always process

Design development employs a large number of design data files that include not only design data, but constraint and verification data as well. When design engineers must manually manage these design files throughout the entire development cycle, they are stuck with a time-consuming and cumbersome process--one that significantly decreases productivity and critically restricts the design development process.

While design engineers should worry about design management clerical tasks stealing valuable time during the development process, an even more important issue warrants concern. Have the designers adopted design management techniques that allow them to completely explore and create the best possible design solutions, given the allotted development time? Because of the fragile nature of the data management process, failing to recognize and deal with under-construction or design-creation management issues can cause organizational paralysis when significant design changes are introduced late in the development process.

Hardware and software development share several similarities. The wealth of information on managing software development, shortening development time, and improving design quality suggests that good data management processes are essential for effective control of the software development process. Good data management continues to stand as a foundation for risk, schedule, and resource management; hardware design complicates this type of data management even more than in software design, which is in itself complex.

Within the domain of software development, code generally progresses through three phases: source code (*.cpp), object code (*.obj), and executable code (*.exe). Each of the steps moves in a unidirectional flow and the different files exist in entirely different formats.

Within the hardware development domain, however, even a simplified flow of code includes: behavioral code (*.vhd), RTL code (*.vhd), and structural (*.vhd, *sdf, *edf) code. Each step along the flow uses VHDL code with the level of abstraction continuously refined. The final step generates three primary files: a structural VHDL design, an SDF design used with the VHDL design for timing verification, and an EDIF netlist file used as input for place and route tools.

Hardware development also requires a long list of tools, including schematic, graphical entry, text entry, simulation, synthesis, and static timing analysis. Hardware design centers on the practice of refining abstraction levels from the algorithmic to the gate-transistor level (see Figure 1). Clearly, refining the abstraction levels process to a design partitioned among several engineers on a team design presents a data management problem and a potential barrier to success.

The data management crisis

Though appearing to suffer from neglect, one aspect of design data management that poses a critical threat to high-density development comes up during the under-construction or design-creation phase. Over a very short period of time, the design team functionally defines, partitions, creates, and enhances a design. As design changes occur and evolve during this phase, the data is constantly changing as well. Upon completion, the design progresses to the manufacturing phase and the product data management (PDM) system takes over from here on in.

Figure 1 - From idea to data
In addressing the complexity of the current design flow, refining abstraction levels to the gate and transistor levels allows partitioning of design tasks among engineers--and presents significant data management problems.

The size of the under-construction data management problem is directly proportional to the data content of any given product. The data content increases with additional product features and, not surprisingly, the implementation and verification of those features require even more data. Today, FPGAs can offer as many as a million gates, enabling engineers to increase the functionality offered in their designs but clearly compounding the data management challenges.

With engineers currently adopting new design paradigms to increase their productivity, new EDA tools have emerged to expedite design definition, analysis, and production. Along with the new tools and paradigms come an abundance of design data files: test-bench source files (VHDL, Verilog, or graphical stimulus files), test-bench ancillary files (ASCII files used by HDL test bench to load stimulus from and/or store output waveforms), test-bench-derived data files (RTL HDL from graphical stimulus tools), design source files (VHDL, Verilog, schematics, graphical bubble diagrams, EDIF), and ancillary data files (user-defined HDL library files, ASCII side files for HDL source and RAM/ROM load files, synthesis constraint files, place and route constraint files). Other design data files include derived data files (RTL HDL from graphical source files, schematics, bubble diagrams, flow charts, EDIF and/or RTL HDL generated from technology-specific macro generators), place-and-route-generated files, and project technical documentation files (such as Word, Excel, PDF, and HTML). These files increase in both number and complexity as the difficulty of a design increases.

The size of the under-construction data management problem is directly proportional to the data content of any given product.

Certain process and design techniques contribute to the large numbers of data files. For example, continuous refinement often finds each hierarchical block in a different phase of completion. Some blocks may be at the RTL level, while other blocks, fully verified, have progressed to the gate level. As the designers move through the various phases of the refinement process, they create additional files. Synthesizing RTL files and the placement and routing of the results in the FPGA produce even more files.

Figure 2 - Chips off the blocks
Each hierarchical design block may consist of multiple views including RTL, behavioral, or structural descriptions.

Each abstraction-level implementation--or view--reflects a VHDL architecture, the consistent interface to the block. Each hierarchical block may have many defined views consisting of the RTL, behavioral, or structural descriptions (see Figure 2). Occasionally, a designer must experiment with different implementation styles to achieve the desired area and speed specifications. In this case, each hierarchical block may contain n different representations at each description level, further generalizing the definition of a view. Therefore, multiple views at the same level of abstraction may coexist.

Below the surface

At one time, FPGA designs consisted solely of schematics and gates, which easily accommodated the then-typical device density. Today, however, a designer faces design sizes averaging in the 20,000 gate range where productivity using schematics and gates quickly becomes an issue; designers increase productivity if they can express design functionality in forms other than schematics and gates. In addition to handcrafted HDL code, expanding the design creation techniques to include schematic, state machines, flow charts, and truth tables adds yet another dimension to the design management discussion (see Figure 3).

Figure 3 - Multiplying data
Design creation can expand to include schematics, state machines, flow charts, and truth tables--each of which contains its own formats and produces its own data.

Each hierarchical block description may consist of multiple source files. The clerical effort required from an average design engineer clearly interferes with all levels of productivity as design complexity increases--each hierarchical block containing a number of views, each view containing several files.

These design data management illustrations include only surface-level issues. For anyone wanting to develop multiple test benches at multiple levels in the design hierarchy of the project, however, the complexity of the task increases quickly.

Test benches also challenge the data management development process. Similar to the design functional description, test benches may use the same format or language as the source files, or even the same hierarchy as the source files. Additionally, multiple test benches per hierarchical element increase the file management requirements even further.

In general, simulators use test benches, while synthesis tools don't, indicating disparate data management requirements. In addition, test benches can and should offer reusability throughout the design refinement process. For instance, the same test bench would then suffice for both pre-synthesis and post-place-and-route functions.

If applying different design processes to sub-sections of the project helps to achieve the correct balance of area, speed, and power to meet specifications, then a slightly deeper understanding of the under-construction design data management requirements emerges (see Figure 4). When a situation requires a functional block--for example, a PCI bus--to run at a given speed, the designer may willingly invest more time in terms of synthesis optimization and place-and-route constraints to meet the timing requirement goals. One strategy sacrifices space for speed, while the remainder of the design benefits from space optimization. Clearly, each functional block requires a different design process as well as different optimization parameters, precipitating yet another design data management problem: How does the design engineer separate hierarchy and manage the related files?

Figure 4 - Speedy and small
Data-centric data management permits options for parameter optimizations, which match the design constraints of a particular block--in this case, area and speed.

Although most silicon vendors have standardized their libraries for EDA use, designers still usually need to connect different representations of the technology library to different tools in the design flow. For example, the vendor provides a schematic library for schematic capture, a macro generator that requires a symbol to be generated, and verification libraries for pre-and post-layout simulation. The vendor's place-and-route tools provide an SDF file for timing analysis. In addition, synthesis target libraries, as well as user-created libraries and preferences, may need managing. The user needs files to direct synthesis and to guide the timing-driven place-and-route tools. Another common practice uses VHDL or Verilog text files to load RAM/ROM modules with values prior to simulation. Library management clearly poses an additional concern in the design data management strategy.

Closing in on data

These issues haven't escaped the engineers who are busy designing and implementing the next set of products for their companies. Depending on the complexity of the design and the skill sets of the engineers, designers have employed several methods: using software development tools (make, RCS) to build hardware development data management systems, employing the configuration functions within the VHDL language, managing all of the design data files manually, or using the data-centric functions offered by some EDA vendors. The inherent limitation of a make-based hardware design data management system is that make--based on rules of files existence--reflects no knowledge of the state of the design.

VHDL configurations offer powerful, but difficult, solutions. They allow the designer to manage the design data for simulation and sometimes synthesis, if the tool robustly supports configurations. However, since VHDL configurations don't present design data in any other format than VHDL, they fail to increase visibility.

As long as the design size is small, the traditional method employed by many design engineers yields acceptable results, although it frequently falters in the area of quality control or repeatability. Common types of questions include, "Did we send the vendor the same design we simulated?"

In fact, all of the under-construction design management issues reveal a common thread: they all relate to the structure of the design as it processes through the design tools. This realization has provided companies such as Veribest with the inspiration to build a technology that allows the designer to have a source view of the design hierarchy.

Figure 5 - Tabbing the hierarchy
The tool ensures proper construction by continually checking the hierarchy for missing files or other errors, displaying them to the user in the hierarchical tab view.

Reflecting the movement of this technology from the power user to the mainstream market, a recent user survey by Dataquest put the majority of FPGA designs in 1998 in the 5,000-to-10,000-gate range. That range should increase from 30,000 to 50,000 gates by next year. The current tool-centric approach threatens productivity deficiencies for the mainstream user at these densities.

Under new management

Veribest's Designview tool addresses the under-construction data management problem for the FPGA users. Actel, for instance, currently uses the tool in its design creation toolset, which provides a portal for viewing and managing users' data through an abstraction layer between the users and the point tools. The users can choose to view design data from a file, hierarchical, or simulation perspective. The management tool then launches the appropriate design tool--automatically, in the case of design creation (the state machine editor), when the data element is selected and initializes the appropriate data in terms of file locations, options, libraries, and output locations. The tool eliminates the clerapproach.

The data remains the most valuable product of the designer's efforts, and design methodologies must evolve to reflect the data's importance.

The file-based view displays the project content in a file system directory structure, grouping the schematic, graphical, HDL text, and simulation test benches into the appropriate directory. The hierarchical tab reveals not only the hierarchical construction but identifies missing hierarchy caused by missing files or typing errors, and continually checks the hierarchy to insure proper construction (see Figure 5). Configuration management, virtual root management, and hierarchical block viewpoints are all supported at this layer.

While the tool manages the data, configuration management provides an easy way to compare implementation options quickly. As the designer switches between configurations from different vendors, the process context immediately changes to display the vendor-specific synthesis results, vendor place-and-route files, and post-route simulation files. Configuration also offers the option to support or compare area-versus-speed optimizations for particular functional blocks. Each functional block can contain multiple implementations or viewpoints; a set of active or selected viewpoints comprises a configuration. This configuration capability enables the design engineer to construct an implementation that optimizes various blocks for speed and others for area.

Virtual root management allows the user to isolate a branch of hierarchy for design, verification, and FPGA placement and routing. The user sets the new root by literally clicking on the hierarchical branch. The tool now carries out all data operations with this new point serving as the top of the design; the function supports mixed-design--schematic, graphical, and text entry--creation methods.

Simulation management moves the user through the simulation process while managing all of the data relationships between source, test bench, and post-route SDF files. The user selects the HDL file for simulation and selects the option to associate a test bench. The test bench initializes with the port knowledge (I/O) of the function to be simulated and then associates itself with this particular function. As the function moves through the implementation process--for example, synthesis or place and route--the tool generates a post-route HDL and SDF file. Designview automatically associates the test bench created earlier with the post-route results, and maintains that association.

Traditionally, configuration, virtual-root, and simulation management are all accomplished manually through design partitioning, copying, and editing. The FPGA design process threatens to cross a threshold in design data management complexity. The continuous refinement nature of FPGA design generates tremendous amounts of data as the designer explores and compares design creation methods and optimization techniques. The data remains, however, the most valuable product of the designer's efforts, and design methodologies must evolve to reflect the data's importance. Managing the data effectively by adopting a data-centric development philosophy promises to enable productivity gains unavailable with current tool-centric methodologies.

Bob Potock has been with Veribest, Inc in Boulder, Colo. for three years, and is currently director of CAE solutions. He has over ten years of engineering and management experience in the EDA industry working with companies such as Cadnetix, NeoCAD, Intel, AT&T Bell Labs, and Unisys.

David Brady is the CAE architect at Veribest. He has over 10 years of experience in the EDA industry at companies such as Mentor Graphics and Trimiter Technologies. Prior to working in EDA, Dave worked as an IC designer for the Northrop Technology and Research Center.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to jeff@isdmag.com.