ensilica custom asic banner

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.

Ensilica custom asic press image

How to write an ASIC design specification well – Part 2

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

Who Is The Specification For

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 second of three blogs on the topic, we look at the audiences for needs the specification and the information they need.

“The specification can (and does) act as the communication channel, helping information to flow.”

Who reads it?

There are two audiences.

1) Your internal system development team. If they lack understanding or agreement of the product’s definition, there’s little chance that the development team can successfully deliver what is required.

2) Our development team. Because it’s natural and common for individual members in a development team to read the sections of the specification focused on their tasks… and only these sections, the specification document allows a development team to be structured correctly and the right skill sets brought together to get it right first time.

Potential pitfalls

However, the specification document does not act as a panacea to magically resolve poor communication between customer and supplier. Nor will it fix potential communication problems between people within a development team, however it can (and does) act as the communication channel, helping information to flow.

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

Click here to read part 1 and part 3.

asic flow

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.

© Copyright - EnSilica | Privacy Notice | Call Us - UK General : +44 118 321 7310 - UK Sales : +44 118 380 5757 - USA : +1 855 642 1070 - India : +91 80 2258 4450