How to write an ASIC design specification well – Part 3

This is a 3 part blog. If you missed it, click here to read part 1 and part 2.

The 7 Most Common Mistakes and How To Avoid Them

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 final part, we look at the most common mistakes and how to avoid them.

1) Loose language

The language used in the document matters. It can add clarity, and it can add ambiguity.
For example, there is a big difference between ‘shall’ (expresses a requirement), ‘will’ (makes a statement of fact), and ‘should’ (expresses an aspiration).

2) Not being concise

Requirements should be as concise as possible, and broken down into individual items to give full clarity when reporting compliance during the development.
For example, it is better to say, “The product must do X” and “The product should do Y” versus “The product must do X and should do Y”.

3) Missing information

Any aspect of the product’s functionality that is missing from the requirements will not make it to specification document. And, therefore, will be missing in the product.

4) Lacking rationales

Rationales should be added for each requirement where appropriate.
But note, these should not be extensions of the requirement. And compliance will be determined against the requirement, not the rationale.

5) How vs what

The requirements describe what the product must do rather than how it must provide that functionality.

6) Including non-essential functionality

If something is not essential for the intended product functionality, then it should not be a requirement.

7) Lacking measurability

Requirements should be clear and unambiguous, and terminologies or expressions that are not verifiable should be avoided all costs.

This means subjective statements like “The product must be low power” should be defined to say “The product must consume less than X”.

And for reporting compliance, there must be a way to uniquely identify each requirement. This enables compliance reports to make clear statements such as “Specification S.17 addresses requirement R.49”.

Getting a specification wrong can be catastrophic. By following these seven tips you’ll be well-placed to get it right first time.

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