The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
General >> Comments and Suggestions >> How to write a specification
https://designers-guide.org/forum/YaBB.pl?num=1132783456

Message started by keble on Nov 23^rd, 2005, 2:04pm

Title: How to write a specification
Post by keble on Nov 23^rd, 2005, 2:04pm

For many years I've been trying to get people to write IC specifications in a way that's clear, concise, unambiguous and so on.
Is there a guide anywhere? I had a google around - lots of info on writing software specs, but nothing on ICs. I suppose the task is rather similar.
Does anyone have any recommendations?

Title: Re: How to write a specification
Post by Ken Kundert on Nov 23^rd, 2005, 3:26pm

Best way I know is to use Verilog-AMS. This does not do too well on the performance, but it does precisely define the functionality, the pin-outs etc. And people actually use the model on a daily basis, so they will keep it up to date.

-Ken

Title: Re: How to write a specification
Post by Paul on Nov 24^th, 2005, 2:30pm

I don't want to enter the discussion on whether specifications should be written in text form or in a hardware description language. I believe both serve different purposes, one on the customer interface side, the other on the designer's side.

Following up on Keble's post, I don't think there's so much literature on this topic, at least I'm not aware of any. This may be an interesting topic for community authoring, where everybody could submit his/her ideas on the topic.

What do you think?

Paul

Title: Re: How to write a specification
Post by sheldon on Nov 25^th, 2005, 4:43pm

Greetings,

My concerns would be:

1) How to effectively capture the process, temperature,
supply voltage, statistical variations in the model.

Do models need functionality similar to Spectre model
files, so designers can change between corner
parameter sets? Should this be supported
automatically, similar to Verilog-AMS connect module
supply sensitivity. That is the simulator would switch
among parameters sets depending on simulation temp,
supply voltage, ...

2) Does it make sense to define specifications without
defining how they will be tested?

My image of what is required is something more like
the ADC testbench Jonathan David presented at BMAS
a couple of years ago. It included the specification
and the measurements.

3) Paul also makes an interesting point, the meaning
of specification changes depending where you are
in the design chain. The level of detail that system
level designers require and circuit designers require
are different.

I would agreee that writing specifications is becoming
more and more important and that there is not a lot of
good literature on this topic. I guess my feeling is that
the place to start would be to have somebody write a
few really good examples. The issue is that writing
specifications will be difficult to reduce to science because
you quickly run into the question, "How good is the
specification?" and "How do you make a specification
better?". These are really tough questions. For now it
seems like learning by example is the only practical
approach.

Best Regards,

Sheldon

Title: Re: How to write a specification
Post by Eugene on Nov 25^th, 2005, 6:54pm

In my opinion, a specification quantifies functionality by defining: 1) performance metrics, 2) interfaces, and 3) minimal acceptable performance. I believe the combination of behavioral models and simulation test benches (also known as an executable specification) is the best mechanism for defining performance metrics and interfaces. For example, with a behavioral model of an LNA in a noise figure simulation test bench, there is no way to confuse double side band and single side band noise figures. In this application, tolerances and drifts are not the issue; all that matters is how noise figure is measured. The measurement defines the specification. One convenient feature of a true executable specification is the ability to replace a behavioral model with the detailed model of a particular block. Thus, if the behavioral model of a programmable gain stage produces increasing gains while the device level model produces an unrecognizable gain pattern for the same command sequence, chances are the detailed model has the bits in the command word reversed. The executable specification detects interface errors. The executable specification is indeed a precise way to implement a specification but it is unwieldy. A specification is also a negotiation tool. The systems engineer uses the specification to budget impairments and hardships among the designers of the various subsystems. Negotiations take place in meetings where a nimble summary of the complete system is essential. Furthermore, even the fastest simulators and models are usually too slow for exploring the initial design space. In these applications, the spreadsheet is unbeatable. The spreadsheet can summarize minimal acceptable performances that account for tolerances and drifts. The spreadsheet can also couple various metrics as well as summarize measurements, simulations, and requirements. I believe executable specifications and classical spreadsheets are both important in writing precise and practical specifications.

Maintaining a specification in two formats requires time and discipline. I think tools linking the two formats would sell well. In the absence of better links, I sometimes keep my behavioral models and spreadsheets synchronized by writing visual basic routines to automatically create parameter files that my VerilogA files can read.

Title: Re: How to write a specification
Post by keble on Nov 28^th, 2005, 1:46pm

Thanks for the responses - some really good stuff there to think about.

I like the idea of producing some examples - I have found an example I wrote some years ago but it's in Lotus Word Pro format (and now I'm on a Mac) so I'll have to figure out how to translate it into something useful!

I like the idea of using a high-level model, and we are starting to do that - at last, top-down design. But I think the spec comes first, then the model, then they should be proved to match - as mentioned by Eugene.

Specs are difficult to write, and the writers have a big range of ability and experience.

I'm putting together some guidelines and I'll post these plus my example on a web site somewhere soon. Meanwhile if anyone has some examples I'd be interested in reading them.

Title: Re: How to write a specification
Post by cybq on Jul 3^rd, 2006, 2:40am

yeah, it is difficult to write a specification as xpected. I always found the datasheet of others are very complete. I think the datasheet should be
able to discribe the IC perfermance as best detailed, and the datasheet should include information the customer required as much as possible.
The work requires that the writer have deep and broad knowledge and pratice experience.