Design Automation

Design Flow Is the Key to Efficient HDL Design

Leo Bredehoft examines the proper choice of tools and methods to put hardware description language within nearly everyone's reach.

by Leo Bredehoft

Inexpensive tools integrate design flow Many public domain or low-cost software development tools are useful in FPGA development. The FPGA development process resembles the software development process, so the two can have development tools in common.

These tools may play a part in producing portable designs (which may be retargeted at multiple vendors' FPGAs) or gate arrays with high-level compile switches. They may reformat netlists, either into gate-level simulation models or for a tool with a different input format. They could also generate logic hierarchy reports (useful in monitoring synthesis output quality) or simply filter irrelevant data out of EDA tool-generated reports.

The key is smoothing and integrating the design flow. Vendors of sophisticated turnkey HDL packages are correct in saying smooth design flow enhances productivity. If engineers can recompile an entire design with a few simple keystrokes, they are encouraged to concentrate on high-level issues rather than keeping track of source files needing to be recompiled, or sifting through reams of tool-generated reports.

Some engineers even edit netlists by hand to compensate for tool weaknesses or to convert them from one format to another. Hand editing is costly, laden with the potential for error, and often unnecessary. Using the tools described below, in a matter of hours one can write netlist reformatters that can reliably and repeatedly do the conversion while saving enormous amounts of time and improving process reliability.

Where HDL-based designs are involved, the development environment design can be just as important as logic design. When engineers are constrained by a budget, the environment design responsibility is theirs. The design need not be costly, either in time or capital.

.
.
.
#define SR8(in,clock,out) \
out/**/_d 
<
= out(7 downto 1) & in; \
dff_v(out/**/_d,clock,out); -- vector D flip flop
.
.
.
SR8(in1,clock1,out1);
SR8(in2,clock2,out2);
.
.
.

Choice of operating system Most of these tools exist for multiple operating systems. While tool selection shouldn't govern selection of an operating system, the choice of operating system does influence the quality of results, and the ease with which they are produced.

The main choices of operating systems are DOS and Unix. Unix is preferred, primarily for its virtual memory capability. Many DOS applications are limited to whatever memory is left from the 640 Kbyte of main RAM, and some applications are even more restricted. For example, earlier versions of the DOS sort utility were unable to handle files longer than 64 Kbyte, making it useless for many FPGA development applications.

DOS versions of FPGA tools are invariably the least expensive of the different platform versions. If one uses a PC with network access to a Unix host, the main make process can run on the PC, and the Unix portions of the code can run on the Unix host via remote shell commands from the PC. If a Unix host is not available, the engineer will have to use DOS and replace memory-limited applications with less limiting ones.

Make The most important tool in the suite is the make program. Make accepts a set of rules and dependencies from a file named "makefile" and uses them to execute only those commands absolutely needed to compile the design, based on which source files have recently changed. This would compare to a compilation script that would compile all parts of a design. If executed with each source file change, such a blind recompilation would waste much time. From the makefile, one may also build dependency trees specifying the compile switches and commands needed to compile the same source files to different architectures or with different options.

Make also permits specification of generic rules for production of one file type from another, with the file types being specified by the suffixes. For instance, if VHDL source files were all identified with the suffix "VHD," and all module-level netlists with the suffix "NET," the set of commands to compile modules needs to be specified only once, and make implicitly reuses the rule whenever any module must be recompiled.

Some processes (e.g., simulation library updates) produce no visible effect other than a change to a cryptically named file buried in a simulation directory. But it is most convenient in the makefile to deal with identically named files that differ only in their suffixes. In this case, engineers may simply update an empty dummy file in their production rules using echo or a similar command, then tell make that the dummy file was the desired product of the rule. Keeping in mind that the suffix choice is the user's, since make permits arbitrary suffixes to be defined, if a VHDL source file named "mux.vhd" is compiled into a simulation library, the production rule might produce a file named "mux.vok" to indicate to make that the compilation was successful.

The C preprocessor and m4 Some cheaper synthesis tools do not support user-generated synthesis libraries, so frequently instantiated logic functions cannot be located in a single place for merging into different source files. For example, it would be inefficient from a maintenance perspective if a design used multiple copies of a specialized shift register source code in multiple source files. A user would ideally like to encapsulate the shift register and invoke it with a single compact call.

This problem may be addressed by the expansion of a text macro. Listing 1 shows a VHDL shift register macro definition and invocation using the C preprocessor. Unique signal names needed in the shift register are passed as parameters to the macro. In each place where the macro is invoked, it is expanded inline into a copy of the original shift register. Libraries of macros can be maintained in a global header file to be referenced in an "#include" statement.

The C preprocessor and similar tools are also capable of conditional compilation, where a switch is specified at compile time from the makefile. This results in the generation of different program code, based on the state of the switch. Listing 2 shows an example of conditionally compiled code using the C preprocessor "#ifdef" directive, which implements a latched multiplexer for different FPGA technologies.

C preprocessing is accessible from most C compilers via a command line option. The C preprocessor is documented in introductory C textbooks, and it may be used to do simple text replacement macro expansions.

The m4 macro preprocessor is available for applications requiring more precise control of output at the character level and programmatic logic generation. M4 does not insert extra blank lines in its output as the C preprocessor does, but its strict syntax requirements can lead to illegible and hard-to-debug macro definitions.

.
.
.
#ifdef VENDOR1 [ -- tbuf with charge storage on output
tbuf(muxout,latcha,ina);
tbuf(muxout,latchb,inb);
tbuf(muxout,latchc,inc);
#endif ]
#ifdef VENDOR2 [ -- multiplexer followed by a latch
latchin 
<
=
(ina and latcha)
or	(inb and latchb)
or	(inc and latchc)
;
dlatch(latchin,latchenable,muxout);
#endif ]
.
.
.

Awk, sed, and perl Three tools which are very valuable for general reformatting tasks are awk , sed , and perl . Awk and sed are line-oriented stream editors that execute an entire script of commands for each line read in. Awk is useful in line-sequential processing jobs because of its embedded C-like programming language, while sed is suited to per-line text replacement tasks.

Perl is a full interpretive programming language designed in part to correct the weaknesses of awk and sed , and to combine their strengths. Unless some reason dictates the use of sed and awk , perl is the language of choice. Perl defines a rich set of features, including file manipulation and system calls.

Perl , awk , and sed all support the use of regular expressions. Regular expressions are a powerful idea in string definition invaluable for reformatting applications. They permit matching of text to complex syntax templates and modification of matching text. The regular expression syntax is sometimes hard to read, but it is worth the effort to become proficient in its use.

For example, in a netlist reformatting perl script, the perl command s/^PIN, *([^:]+):([^ ]+) "([^"]+)"..*$/p=\2, m=\1, s=\3/ would convert the line, PIN, MODULENAME:22 "SIGNALNAME" END OF LINE JUNK !@#$%^%& into the line p=22 , m=MODULENAME, s=SIGNALNAME.

The string identification, reformatting, and rearrangement job performed above would take many lines in a typical programming language, but it is simplified with a regular expression-driven substitution. This example, of course, does little to clarify regular expression syntax. It is intended to demonstrate how powerful these tools are in reformatting work. One must consult the references to learn more.

Synthesis and place and route tools frequently use ASCII guide files generated by the user to constrain tool operation. Engineers may consider it desirable to keep the guide file information in the HDL source file (for ease-of-maintenance) and generate the guide file at compilation time. To do this, they can include in the HDL source special comments recognizable by a perl / sed script and written to a temporary guide file before compilation.

In the VHDL module source, the user might include commentlines of the form --ctr <guide file information>. A sed file creation script could contain the substitution line /--ctr/ {s/^[ ]+--ctr //;p};d and the output of the script would consist of only the guide file information from "--ctr" lines.

Engineers may even wish to modify signal or gate names in the flattened netlist to make them more readable during simulation. For example, a hierarchical netlist may contain multiple instances of a module named ADDRLATCH, called ADDRLATCH0, ADDRLATCH1, etc. It would not be surprising to see flattened output that contained module and signal names of the form "ADDRLATCH0/ADDRLATCH/...". These long names can be a nuisance when searching through lists of signals in a simulation. It is easy to write a perl/sed script to find such names and shorten them to a form of the engineer's choice.

It may also be necessary to modify netlists to ensure tool compatibility. Tools advertised by the vendor as compatible with other vendors' netlist formats may be so only under certain circumstances. The above-mentioned text modification tools provide engineers with an alternative whereby they can eliminate differences between one vendor's output and another's input requirements.

Sort An ASCII file sorting utility can be very valuable in reformatting and statistics generation. In some netlist reformatting tasks, a pinlist-format file must be converted into a netlist format. Pinlists arrange a design into lists of components with signal labels on each pin. Netlists list components separately from the signals attached to them and then list signal names, each followed by a list of the component pins on the signal.

To convert from one form to the other, the source file is run through an awk or perl script that scans the input and generates output with sort keys prepended to each line. This result is then passed to the sort utility, which sorts on the keys, yielding an output that has the order needed in the target format. Then, another awk or perl script is run on the output to strip off the sort keys and generate a file in the target format.

For example, in a pinlist to netlist conversion, the input file has gate records of the form shown in Listing 3. The output of the first awk / perl script would be as shown in Listing 4.

The sort utility would group all gate specifications at the beginning of its output and all signal specifications at the end. It would then be a simple task for the final awk / perl script to generate a netlist file from the sort utility output.

Some static timing analysis packages generate huge amounts of report data impractical for the engineer to sift through. With the use of awk or perl , engineers can reduce a 100-Kbyte timing report to only several pages. The sort utility can be used to order the output for intermediate processing and for final readability.

GATE <gatetype> <gatename>
PIN <pinname> <signalname>
PIN <pinname> <signalname>
PIN <pinname> <signalname>
END

1 <gatetype>> <gatename>
2 <signalname> <gatename>/<pinname>
2 <signalname> <gatename>/<pinname>
2 <signalname> <gatename>/<pinname>

LISP When a synthesis vendor provides no means to evaluate the quality of his program's output, it may be worthwhile to write a logic hierarchy report generator. LISP is a programming language well-suited to this job.

Starting with a pinlist, engineers can reformat each combinatorial gate in the synthesis output into a LISP fragment that defines the gate output signal name as an atom whose binding is a list containing each of the inputs. The fragment also adds the atom to a global list of names. The file containing the fragments is then executed by a LISP interpreter, and a small routine is executed that traverses and prints out the signal hierarchy underneath each of the signals present on the global list.

Engineers must be prepared to learn a little about LISP, and be prepared to deal with recursion and LISP's applicative programming environment, if they plan to write a hierarchy report generator. If the engineers have the emacs text editor on hand, they already have a LISP interpreter built in to the editor, and it may be possible to use that interpreter for a hierarchy generator.

Automating design flow Engineers do not need to spend hours examining and modifying tool output with a text editor­possibly corrupting it in the process­each time a revision takes place. User intervention is minimized, and productivity is maximized. Some of the techniques herein seem trivial, and some require more effort; but all save time, effort, and money.

These techniques were used on two designs now in production: a Xilinx 3042 and an Actel A1280. The EDA tools used, aside from the FPGA vendor's flattening and place and route tools, were V-System/Windows VHDL simulator from Model Technology (Beaverton, OR) and the CORE logic synthesis product from Exemplar Logic (Berkeley, CA). The logic designer developed the remainder. The make program for the process ran on a 486-based personal computer running DOS, and invoked netlist reformatters that ran on a networked 486-based personal computer running SCO Unix.

Leo Bredehoft is a software/hardware design engineer with Netrix in Longmont, CO. He holds a BSEE from Wichita State University.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  June 1995