How to write an ASIC design specification well – Part 1

The Purpose Of The Specification

The first step in developing a new ASIC for any function – be it a wireless chip for a wearable healthcare sensor device, an autonomous vehicle ASIC, or a communications system for a satellite – is the specification.

To ensure the product you need is produced, is done so on time and on budget, and that errors aren’t introduced that could require a recall, the specification has to be written clearly and concisely.
In this, the first of three blogs on the topic, we look at the purpose of the specification to help you avoid some of the most common mistakes.

“One common misconception is that the specification can serve as a datasheet or user manual. It cannot and does not.”

The specification’s purpose

To get it designs right first time, it is crucial to clearly define the required functionality and behaviours that the product must possess; and the specification is there to define these. And to also state that any functionality that is explicitly not required.

Who writes it

Typically, the engineering team generates the specification in collaboration with the end customer. It will be based on a requirements document, which will be provided by the customer.

What the document enables

Instead, the primary role of a specification is to unambiguously set out the customer’s requirements. With each customer requirement directly or indirectly addressed by the functionality defined in the specification.

There should be a clear mapping, (one-to-one / one-to-many), between each customer requirement and each function defined in the specification.

What it should not be used for

One common misconception is that the specification can serve as a datasheet or user manual. It cannot and does not.

What happens once it’s written

Once written, it is essential for the customer and development team to thoroughly review and approve the specification and ensure it adequately meets each requirement.

Additionally, the compliance report prepared by the development team should be reviewed and approved by the customer to make sure everything has been interpreted correctly.

If you want to find out more about how EnSilica can help, click here.

Click here to read part 2 and part 3.