Design specification: The cornerstone of an ASIC collaboration

Engaging with an ASIC development partner can take many forms. The intended chip may be as simple as a microcontroller, as sophisticated as an AI-based edge computing system-on-chip (SoC), or even a large language model (LLM) AI accelerator for data centers. The customer design team may include experienced ASIC design, verification, and test engineers or comprise only application experts. Each customer relationship is different.

Yet they all share one fundamental need. The customer and the ASIC developer must agree, in greater detail, on what they are trying to build. That is the role of design specification documents. At Faraday, this document is the cornerstone of conversations between customers and chip design teams, covering critical decisions throughout the design process. The topics can range from initial feasibility estimation through sign-off and beyond.

If the design specification is so important, an obvious question arises: how do you construct a specification that will result in a successful ASIC design experience? However, the real answer is that a successful design specification is a joint effort between the customer and the ASIC development partner.

So, there must be a comprehensive, cooperative, checklist-driven procedure for creating a design specification. It allows to mesh smoothly with customers’ design teams, whether they are starting with only a wish list of features or with a detailed design plan. It also works across a wide range of sizes and complexities in today’s ASIC landscape.

What design specification does

The design specification will serve many purposes during the ASIC design. Fundamentally, it will list the design requirements for the ASIC implementation team. As such, it will serve as a shopping list of silicon IP to be included in the design, an outline of the architecture that integrates that IP, and a guide for integration, verification, and testing.

Less obviously, the design specification can be a point of reference for discussions that will take place between the customer and the design team. What exactly should this block do? How much power can we allocate to this function? Does this alternative approach to implementation work for you? All these discussions can begin with the design specification.

Also, the specification can be invaluable for tasks where the customer is often uninvolved. For example, knowing the design intent and how the chip will be used can be priceless in developing verification plans, self-test architectures, test benches, and manufacturing test strategies. Information from the design specification is vital for detailed design activities, such as determining clock architectures and power-management strategy, in which the customer would typically not be directly involved.

Key elements of design specification

So, what goes into the design specification? There are several important categories of information. The most obvious is a set of functional requirements—what the chip is supposed to do. Often, this will be a list of features, but it may be much more detailed. It’s also essential that the specifications include performance, power, and area requirements.

These will influence many conversations, from our initial feasibility assessment to foundry and process selection, library selection, and power-management strategies. And much of this information will be included in the specifications.

It’s also essential to capture a description of the system in which the chip will operate, including the other components. For example, which SPI flash chip will be used for an external flash? The minor differences in SPI protocols between memory chips can determine which SPI controller IP we select.

Another essential kind of system information is more physical: the thermal and mechanical environment. Heat sinks, passive or forced-air cooling, and so on will influence power management and package design.

Not just what, but how

The specification is not just a list of requirements. It also jointly develops design plans for implementing the chip. Chief among these is the gross architecture.

The architecture of an ASIC may be implicit in its function. For instance, a microcontroller may be a CPU core, some memory on a memory bus, and some peripheral controllers on a low-speed peripheral bus. However, a more elaborate SoC may have several CPU cores clustered around a shared cache and a hierarchy of buses, determined by the bandwidth and latency requirements of particular data flows between the memory and IP instances. If the customer hasn’t already decided on architecture, the design team will develop a proposal and review it with the customer.

Figure 1 An example of the proposed architecture for the customer is highlighted in a comprehensive diagram that describes the architecture and provides additional information. Source: Faraday Technology Corp.

In some cases, the customer will already have architecture in place. This may be because the chip extends to an existing product family. Or it may use a network-on-chip (NoC) scheme or something entirely original, such as a data-flow architecture designed to accelerate a particular algorithm. In these cases, ASIC designer’s role is to ensure that the information in the specification is complete enough to capture the design intent unambiguously, to drive the selection of IP with the proper interfaces, and to adequately inform about the chip layout.

The specification may also include information about specific IP blocks. If a block is a controller for a standard interface—say, a USB controller—then there needs to be enough additional information. For instance, it should be a Gen3 USB host with power delivery to allow the design team to select the appropriate IP.

In some cases, a functional block may be something unique. This often happens when the IP is customer specific. In these cases, the customer must provide enough detail for the design team to create and test the block. This may be simply a detailed functional description. Or it may require pseudo-code or Verilog code for critical portions of the block.

Pulling it together

Altogether, the design specification becomes an agreed-upon statement of what the customer requires and what the design team is designing. But which parts of the document come from the customer, which are jointly written, and which are supplied by ASIC designer for the customer to review vary widely from case to case.

At Faraday, we have developed a formal process, called e-cooking, to collect the data. The process begins with a request for a quote from our sales organization. This RFQ will often contain much of the information we need for the design specification.

With RFQ in hand, we assign an engineer to the project in a role we call a technical consultant (TC). TC begins working through a design checklist to transfer information from the RFQ to the design specification.

When an item is missing or requires more detail, TC will contact the customer, explain what further information we need and why, and obtain the necessary data. If the item requires information the customer can’t provide—for instance, a choice of logic libraries—TC can ask the Faraday design team for input, which we then share with the customer for review.

The completed design specification document is a blueprint for the chip design. It will provide information regarding architectural and IP selection, verification, test plans, and packaging choices. It will also explain the statement of work, which describes which design tasks will be done by the customer and which by ASIC designer.

Figure 2 Technical consultants and engineers enter all project information into the e-cooking system, a tool that tracks the chip’s content. Source: Faraday Technology Corp.

The e-cooking process aims to capture customers’ design intent and the work they have already done toward implementation (Figure 2). The designers enter information into the tool, such as the actual cell size and name, silicon area, quantity, spacing, and I/O.

Next, ASIC designer reviews any suggestions for changes or additional data with the customer team. That brings clarity on what ASIC designer intends to implement at the start of the project. By the end of the project, the only surprises are how smoothly the two teams worked together and how well the delivered chip met customers’ expectations.

Barry Lai heads the System Development and Chip Design department at Faraday Technology Corp., a leading provider of ASIC design services and IP. With 20 years of experience in IC design, Barry specializes in SoC integration, specification definition, digital design, low-power design, and integration automation.

Related Content

• Best practices for structured-ASIC design
• Arrow and Avnet launch ASIC design services
• Why ASIC Design Makes Sense for LLM-On-Device
• An FPGA-to-ASIC case study for refining smart meter design
• A 12-point overview of the advantages of custom analog ASICs

The post Design specification: The cornerstone of an ASIC collaboration appeared first on EDN.