Which came first? The design or the spec?

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.7, Item 4.0)

From: Dave Otero

I to address a different issue in your book. Having been on both sides
of processor development (Design and implementation AND functional
verification), I was wondering if you could comment on the issue of
requiring a detailed and precise specification as a starting point of
your reconvergence model.

- The design side claims that this is an impossibility as the details
and preciseness of the design (Processors) are dynamic to the point
that a specification is really unknown until the implementation is
complete.

- The verification side claims that to identify testplan, test
environment (i.e. test benches, models, etc.) and scope (unit vs
system) it requires knowledge of the design in the form of a
specification to be used as a guide in identifying functions to be
verified.

We have tried to agree on what a specification should include but have
never reached that agreement and end up with designers dictating what
needs to be tested and many times how to test. Could you expand in a
more concrete way (real world example perhaps) what is meant by a
specification, what are some required items to be included in a
specification e.g. Interface timings w/diagrams, State Machine valid
states and transitions, Illegal operations, interface protocols, etc.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.7, Item 4.1)

From: Janick Bergeron

The ideal verification project would have a detailed, final, and
forever unchanging. However, I recognize that reality is somewhat
different :-). But you must be careful not to start coding too soon.
Careful planning and design will save time and effort in the long run.

I have been involved in projects where the customer did not know what
they wanted. Their specifications were simple statements like "we need
the same functionality as before with these additional features". And
the previous design had been similarly vaguely specified. And the
previous one. And the previous one. We could have started the project
4 months later, it would not have made a difference.

In my opinion, before RTL coding, a specification document should
contain all the necessary information to be able to design a "system"
around the future design. Since the RTL coding has not started, the
specification document should not yet imply a specific implementation.
It has the sufficient information re-implement the design, possibly in
a different technology. Some RTL coding may be necessary during
specification to explore its feasibility in the target technology.

For all designs, this necessary and sufficient information includes
detailed interface specifications (pins, directions, timing,
protocol), programmer's model (registers, configuration), and data
transformation from input to output. Additional information may be
required depending on your design. Some implementation-specific details,
such as latency, throughput, side-effects and data dependencies may
not be relevant at this stage.

From that specification document, it will be possible to start the
specification and implementation of the black-box testcases. Once the
detailed implementation proceeeds, and sensitivities of the
architecture to certain input conditions arise, the verification plan
is augmented with grey- and white-box testcases (AFTER the
specification document has been modified to reflect those
sensitivities).