Software Metrics Lead the Way to Better HDL Coding Practices

Software designers have long used simple measurement systems to help them work more efficiently. Hardware designers can use these same techniques to streamline their design processes and facilitate code reuse.

by Gregory P. Chapelle and Michael L. Lewis

Developing a VHDL hardware design on time and within budget while satisfying all the system requirements can seem a daunting task. Throw into this mix the desire to reuse VHDL modules and the need to keep costs down and versatility up, and conceivably a high-wire performer may have an easier time than the typical hardware designer. Since hardware designs rely significantly on the hardware description languages Verilog and VHDL, it makes sense to try to improve the productivity and reliability of the designs using software design methods.

The hardware description languages (HDLs) serve to develop ASICs and FPGAs in a manner similar to that of traditional software development. Software design methods seek to maximize visibility into the design process, permitting managers and engineers to determine if a project is progressing on-track or is failing to meet technical, schedule, or cost goals. Fortunately, the distinct differences that do exist in development between software and VHDL don't limit the application of software methods to hardware design. For example, after designers have debugged and routed VHDL code, they must feed device trace delays back into the simulation to verify that the hardware function remains correct. The software development cycle, however, lacks a similar step. To verify the proper operation, both languages need to be compiled and run--a very time-consuming and iterative process.

We focus on VHDL to demonstrate the software methods, but this approach applies to Verilog designs as well. To extract the maximum capability from VHDL, the status of the VHDL coding must be visible. In particular, if the design team intends to reuse VHDL code, then they should follow a modular software approach.

Listing 1 - VHDL code sample
-- Comment Line ENTITY device IS PORT (a, b : IN BIT; c : OUT BIT ); END device ARCHITECTURE top OF device IS BEGIN Statement_1; Statement_2; -- In Line Comment END top;

A number of software design methods can serve the needs of hardware design. The Capability Maturity Model (CMM) developed at the Software Engineering Institute (SEI) discusses in detail the steps needed to achieve coding improvement, a process readily adaptable to digital design hardware description languages. The underlying key is to collect metrics on the code development. Without some measure of visibility no corrective action can be taken and without corrective action any improvement will remain just a wishful dream. By adopting some of these software techniques in HDL development, we can achieve design schedule milestones, develop products within budget, and produce products that meet our customers' technical requirements.

VHDL as software

The similarities between the Ada software language and VHDL illustrate why a software approach makes sense. VHDL is an offshoot of the very-high-speed integrated circuit (VHSIC) program funded by the Department of Defense in the early 1980s (see Listing 1). To the more experienced VHDL designers the following discussion may seem trivial, but it helps to illustrate the software similarities. Within VHDL, the entity defines the most basic building block in a design, and defines the inputs and outputs. The architecture block describes the behavior of the entity, and a single entity can be used in multiple architectures. Semicolons end a variable declaration or statement, and a "--" at the beginning of a line or after a semicolon delimits comments, similar to Pascal or Ada.

The programming language Ada, first standardized in 1983 by the Department of Defense, was named after Ada Lovelace (daughter of the English poet Lord Byron, who worked with Charles Babbage to develop programs to run on his calculating machines in 1833). All Ada programs share a basic structure (see Listing 2). The procedure declaration names the program. Variable : Some_Type declares a variable. If the variable were an integer value, the declaration changes to Variable : Integer;. Alternatively, Variable : Float; declares a floating-point (decimal) value.

Semicolons always end a variable declaration or statement, providing the ability to place more than one variable declaration or statement on one line. However, most programmers recommend starting each statement on a new line and writing no more than one simple statement per line. Comments are prefaced by "--", and may be on a line by themselves or may follow a statement's semicolon.

The listings reveal that VHDL and Ada share a similar structure, perhaps owing to their simultaneous development by the DOD at nearly identical times. Statement lines in both languages are delimited by semicolons, and comments are prefaced in identical ways. The Ada PackagesName is similar to the VHDL entity, and a VHDL architecture is similar to an Ada procedure. Both Ada and VHDL include blank lines or white space, comment-only statements, in-line comments, and statement-end semicolons. The loop and conditional statements of the two languages are also very similar (see the table).

Listing 2 - Ada code sample
-- Commented Line with Package_Name; use Package_Name; procedure Program_Name is Variable : Some_Type; begin Statement_1; Statement_2; -- In Line Comment end Program_Name;

Software design methods

The similarity between these two languages points to how software design methods can facilitate hardware development. A look at the software design methods suggests those that could yield the greatest improvement in hardware development.

The U.S. Department of Defense established the SEI (http://www.sei.cmu.edu) in 1984 to advance the practice of software engineering. SEI advances the state of the practice of software engineering by promoting the evolution from an ad hoc activity to a well-managed discipline supported by technology. During this time, the SEI developed the Capability Maturity Model for software development, in order to help organizations predict and control quality, schedule, cost, cycle time, and productivity when acquiring, building, or enhancing software systems. CMM also gives engineers the ability to analyze, predict, and control selected properties of software. This approach addresses the significant issues impeding the ability of organizations to acquire, build, and evolve software systems predictably on time, within expected costs, and expected functionality.

The CMM provides not only a technical approach to individual software development, but also an organizational shift to a team approach. The software organization uses the model to progress in stages, with the CMM organized into five maturity levels, from Initial to Optimizing. In the Initial level (the first level), the software is characterized as ad hoc, and occasionally even chaotic. The second or Repeatable level establishes basic project management processes to track cost, schedule, and functionality that similar projects can repeat. The Defined level (the third level) enumerates a standard documented process for both management and engineering in developing and maintaining software to be inte-grated into the organization. In the fourth or Managed level, the organization collects detailed measures of the software process and product quality. Finally, the fifth or Optimizing level mandates continuous process improvement by way of quantitative feedback.

Each maturity level, except for the first, comprises several key areas that an organization should focus on to improve the software process. The Repeatable level focuses on the software project's concerns related to establishing basic project management controls. The Defined level deals with both project and organizational issues to institute effective software engineering and management across all projects, including intergroup coordination, and peer reviews. The Managed level focuses on a quantitative understanding of both the development process and the products being built. Optimization addresses organization issues concerning the implementation of continual and measurable software process improvement, primarily in the form of defect prevention, new technology incorporation, and process-change evolution.

To apply this multilevel software design approach to hardware development, the design team must amass a collection of design metrics. In software development, metrics--standards of measurement used to determine distance from a desired value--can encompass many things, depending upon the organization. In a typical software design they may include statistics on the size of the specifications, the hours of preliminary design prior to coding, the lines of code written, and the number of comments in the code. For a VHDL design the number of lines of code, the amount of commenting, the defects per 100 lines of code, and the number of hardware gates developed, can comprise significant metrics that offer insight into the development.

A properly designed metrics program measures a few critical aspects of the development. Gathering metrics data should not impose a burden on the technical staff. Ideally, the metrics data should be obtained directly from the development process, instead of needing a separate effort. If the process takes too much time and effort away from the design work, then the designers will perceive the metrics program as a lower priority and thus slight it. Similarly, even though hundreds of project metrics could be collected, the best success results from selecting only a small number of metrics--those that provide the most useful insight and information.

A metrics program should provide simple, direct indications about the quality of the process and product as well as the progress of the project. This simplicity promotes a directed dialog between management and the designers to help highlight areas needing more people or resources, and to gauge the technical effort being
expended by the technical staff. The teams can apply a whole range of metrics, from measuring how different teams are coordinating, to determining the amount of design reuse viable in an organization.

Using metrics

An example of a useful metric is an automated code counter for software development that gathers the number of lines of code, the stand-alone comments, the in-line comments, the number of loops, and other similar coding items. Relying on manual collection efforts leads to different approaches by different designers and hence the need for automated collection programs. In addition, lack of standardization can of course skew the data. The collection of coding statistics can also prove tedious and prone to errors for large designs. The automated approach reduces the time involved for the metric collection. After all, if a metrics program is to succeed then it must utilize the metrics to gain useful insight into the design, and not simply validate the gathering of the statistics as a task unto itself.

Table - VHDL and Ada compared
	Ada	VHDL
Conditional
Case	case [test] is when value1 =* statement_1; when value2 =* statement_2; when others =* statement_3; end case;	CASE [test] IS WHEN value1 =* statement_1; WHEN value2 =* statement_2; WHEN OTHERS =* statement_3; END CASE;
IF, ELSE, ELSEIF	if [test] then statement_1; elseif test2 then statement_2; else statement_3; endif;	if (condition) THEN statement_1; ELSEIF (condition2) THEN statement_2; ELSE statement_3; END IF;
WHEN	Not applicable	See case statement above
Exception	defining_identifier_list : exception;	Not applicable
Loops
EXIT	exit [loop_name] [when condition];	EXIT;
FOR	Not applicable	name : FOR i IN start TO end GENERATE sub_name : component PORT MAP (a(i),b(i+1)); END GENERATE

Equally important for the project is how not to use these metrics. For example, program management shouldn't use the number of lines of code to identify productive versus unproductive technical staff. The number of lines of VHDL signifies a design's complexity and must remain an objective statistic. Otherwise, worried designers will refuse to collect the metric data, or will perhaps fudge the numbers to make themselves look better, thereby negating the whole metric collection effort. A typical scenario allows for gathering metrics periodically--approximately once a week if design work is hot and heavy, or less frequently if the VHDL design is underway in conjunction with other program issues.

Graphically plotting this metric data can prove useful for extracting various trends (see Figure 1). In the good design approach (see Figure 1a), notice that as the design progresses the "total lines of code" curve flattens out. This graphic elbow can help to determine when the design is in the final phase of fine tuning, or still in an early phase where lots of code is being written. Additionally, the number of blank lines or commented lines (relative to the number of total lines) provides insight into whether the VHDL code is sufficiently commented or contains enough white space for ease of reading. The use of white space in code development should not be understated, because the ability to pick out pieces of the design from within the source code can significantly improve understanding. Obviously, few hard and fast rules exist for how much code should contain comments, but a minimum of 20 percent (1 in 5 lines) serves a good starting point. For VHDL intended for reuse, such as in IP cores for ASICs, designers should increase the amount of commenting, which facilitates understanding and eases code revision.

Graphing the collected metric data can identify more disturbing trends (see Figure 1b). For instance, a dramatic increase in the number of comments added towards the later part of the design masks the reduction in source-line development after week 3 in the metric for total lines developed. Waiting to insert comments until late in the design represents bad coding practice (but not necessarily bad designers). Late comments may be less accurate because the code has become stale in the digital designer's memory. The commenting of VHDL, the bane of any designer, should always take place concurrently with the detailed digital design. Designers must recognize that this practice helps to insure organizational success for the project. Comments recorded as the designer develops code for a particular subblock prove far superior to comments added three or four weeks after the code was written--a period when the exact reason for writing the VHDL in that particular way has evolved from an at-the-fingertips to a hazy recollection.

Figure 1 - VHDL code status
Metrics can illustrate the differences between good (a) and bad (b) design methods. Both teams complete most of the running code by week 3, but the better method contains more blanks and inserts comments earlier.

The hierarchical design approach available in VHDL also means that metric collection can occur at any desired depth in the design. We found that if we collected metrics at the top level of a design and also at one level lower in the hierarchy, the information provided engineers and managers with insight into the design. This coverage allowed the team members enough flexibility to study the overall VHDL, while maintaining the ability to focus on the subblocks that were causing the more difficult schedule, cost, or technical issues. The team could present the information gathered in several ways, then go on to use the metrics in subsequent design reviews.

The statistics for all of the subfunctions within a design can reveal the relative importance of each block (see Figure 2). This kind of chart serves effectively in design reviews to highlight the internal design aspects and the human resource allocation issues associated with a design. The information also helps to gauge the level of effort needed and improves estimates for the duration of the design.

Figure 2 - Hierarchical subblock metrics
Block 1 clearly makes the largest impact on the overall project, and potentially creates the highest risk because of the large number of coding lines. Block 3, in contrast, is the simplest design in terms of coding design complexity.

A collection of metrics can serve a design team's long-term goals as well. If we can collect the number of lines of design code developed over time, then in future projects we can have a better handle on estimating the design time. By better estimating the design time, we can better manage our costs. The use of the metrics within an organization is limited only by imagination. In fact, making the design work comprises only a small part of overall usefulness of this type of information.

Gregory P. Chapelle is a digital systems engineer at TRW Avionics Systems Division (ASD) in San Diego. He has over 13 years of experience in digital design and systems engineering in avionics products.

Michael L. Lewis is a digital designer at TRW ASD, where he has designed, integrated, and tested ASICs and FPGAs using VHDL.

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