If a design specification doesn’t take into account verification needs, the development schedule is in jeopardy before the project has even begun.

Historically, the full purpose of an integrated-circuit (IC) design specification was to tell designers what to design. As more complex designs were developed, the firmware development schedule became longer than the hardware development effort. As a result, firmware considerations had to be taken into account and specified in the early documentation of the chip. Today, the increasing complexity of designs requires verification testbenches that are larger and more complex than the design that they’re required to prove. If a design specification doesn’t account for verification needs, the development schedule is in jeopardy before the project has even begun.

Document Organization
The organization of the specification document contributes greatly to the success of a project. A specification that’s easy to reference leads to less time spent in word searches or calling architects for information. Rather than adding a table of contents as an afterthought, one should be provided that’s both useful and in-depth. A detailed table of contents can supply a massive amount of information that leads to quick understanding of the IC.

Specifically, the table of contents should provide the following:

• The organization of the specification document
• The location of information about major design blocks
• Where to look for IC details like waveform diagrams and I/O pins
• Where to go to find detailed information about internal (block-to-block) interfaces and registers

Keep in mind that “more is better” should be the guideline when creating the table of contents. In addition, always use hyperlinks for table-of-contents entries.

A designer often works with only a small portion of the specification to develop his assigned portion of the product. Firmware engineers are usually interested in the registers, memories, and interrupts. For their part, verification engineers must work with the entire specification. These engineers are interested in what’s outside the IC in addition to the internal operation of the design. To a verification engineer, a top-down approach to the specification, which describes the overall IC operation before diving into the details, is a critical tool when developing the verification environment.

The following document organization provides a good flow for those who must comprehend the full operation of the design from the specification:

• Introduction
• Related documents
• Product requirements
• System overview
• A day in the life
• Functional overview
• Data-flow descriptions
• Input and output descriptions
• Major functional-block descriptions
• Memory map
• Register descriptions

Often, verification engineers are members of a different group within the organization. As a result, they may be unfamiliar with the organization developing the project. To eliminate the resulting issues, one should provide contact information for the major players on the project within the “introduction” section of the document. It’s essential to specify the name and contact information for chip architects, design leads, firmware architects, and testbench architects. Group managers, marketing leads, and project managers should be listed as well.

Related Documents
Note that hardware and firmware design engineers will often work on closely related products or multiple generations of a single product. The level of expertise in the field therefore precludes the need for a lot of related documentation in support of the specification. Yet this is not often the case with verification engineers. Verification work on a project can be divided into multiple stages:

1. Verification planning
2. Testbench architecting
3. Testbench implementation
4. Testing and tracking

The third step in this process requires a massive amount of manpower to develop the models, monitors, checkers, and scoreboards needed for the complete verification environment in time to be used by early design-verification efforts. This means many verification engineers will come onto a project late and for a short time and then move on to other projects. Of course, they won’t be experts on the given product.

In the “related documents” section of the specification, it’s critical to supply references to industry standards, internal IP specifications, product requirements, and any other document needed to understand the project. Also, be sure to specify the third-party design IP that will be used in the product. It also may be helpful to include overview or marketing literature on these products.

Finally, supply references to documents specifying representative outside components that interact directly with this product in a system. The verification engineers will be supplying models for these components in the testbench. The reader also will need to know how to access the documents. Please note the following points:

• Freely accessible documents should contain details regarding how to do so.
• Restricted or purchased documents must specify how to gain access or supply a contact that can provide temporary access to the document.
• Any document that’s completely unavailable must be accompanied by a contact who can answer questions from the document.

Product Requirements
The product requirements form the beginning of the verification plan. If a separate document exists that specifies the product requirements, this section is unneeded. That document is referenced in “related documents.”

System Overview
The system overview shows how the product fits in a larger system. It also explains what it does for the system. Keep in mind that the verification team won’t be designing the product. They’ll be designing a model of the system in which the product resides. The intent of this section is to describe exactly what needs to be developed for the verification environment. The specification writer doesn’t specify how the system will be modeled—only what needs to be modeled.

Be sure to include a diagram and text that describes the product within the larger system (see Figure 1). A hard-disk read channel specification, for example, may show a diagram that includes the pre-amplifier, disk controller, etc. In addition, all peripherals that are to be connected to the product should be specified. This would include displays, buttons, switches, industry-standard bus connections, etc. When possible, existing examples of each peripheral should be named for reference purposes. The diagram doesn’t need to delineate individual pins. But major interfaces that interact with neighboring components should be labeled so that they can be found in the text.

Figure 1: The system-neighborhood diagram shows the functional connectivity between the product and the neighboring parts.

It also is helpful to explain the operation of the product within a higher-order system. Where industry-standard interfaces exist, operations, functionality, and interactions can be specified using the terminology appropriate to that standard. This description should contain the purpose and key features (relating to this product) for each neighboring part. Also, include a system-level block diagram showing data flows. This can be a copy of the system-neighborhood connectivity diagram that has directional arrows and accompanying descriptions describing the flow of data and control in the system. To supply a clean, easily readable diagram, it’s advisable to include less bus and port naming. If more information is provided in this section with clearer descriptions, verification engineers will spend much less time camping outside the office of the architects.

Functional Overview
It also is important to provide a functional overview that describes the internal functionality of the product. Major block partitions and I/O interfaces should be described including the following information:

• What does the block or interface do? Explain the major functional features of each block and how they affect neighboring blocks. Internal block functionality that’s not relevant to this high-level overview shouldn’t be included here.

In addition, the functional features should be specified with respect to their impact on product requirements:

• Why does it do it? Explain the purpose of the block or interface in the larger system. The verification team uses this to determine what needs to be verified.
• When does it do it? Explain the external or internal events that cause the block to do each of the tasks. This is critical for test generation.

One should include a block diagram showing the functional connectivity of each major block and interface (see Figure 2). Any standard or third-party IP blocks that are included in this design should be highlighted. It isn’t necessary to describe “how” (algorithmic information) for the blocks and interfaces in this section. This will be described separately under individual functional-block descriptions.

Figure 2: The block diagram shows connections between internal design blocks.

By using data-flow descriptions (see Figure 3), one can tell how the various internal blocks communicate with each other. Be sure to supply at least one block diagram showing the data flow and control/communications flows in the part. This can be a copy of the diagram from the functional overview with the addition of arrows and labels showing data and communications flows. If multiple data flows exist, it’s necessary to generate multiple diagrams. If the part contains programmable operational modes in which the data flow differs, a diagram should be supplied for each operational mode. Include text with each diagram that provides details for each communication and control channel as well as each datapath shown.

Figure 3: In this data-flow diagram example, the disk data read flow isn’t shown due to congestion. It would be shown in a separate diagram.

A Day In The Life
The DITL is a concise description of how the product does what it’s supposed to do. Verification engineers use it to create verification scenarios. Supply a DITL that answers the following questions:

• When the product is in a system and turned on, what typically happens?
• What happens first? What is next? What happens in parallel?
• How do things end? What happens when the product is turned off?

Explain the high-level operation of the product so that all project members understand what the part does. A good DITL allows everyone on the project team to understand how the product does what it’s supposed to do.

References:
Verification Plans by Peet James, 2004, Kluwer Academic Publishers

Dave Fechser has worked in the IC industry in hardware design, firmware development, and verification. He currently works as a verification engineer at LSI Corp.