5
\$\begingroup\$

Especially for something like a microprocessor.

I assume the majority of information is "auto-generated" or we'd see a lot more typos and errors.

A laughable scenario keeps popping into my head where a handful of engineers pass around a word document, export it as a PDF and then manually apply bookmarks.

Are these companies big enough that they can afford to have departments that churn out custom software, databases, etc. to assist their design process?

I'm very curious because I'm finding it very hard to keep data/information/specifications uniform throughout the design process.

Maybe this question belongs in a different exchange?

\$\endgroup\$
  • \$\begingroup\$ The datasheet is a codification of the specification's for a part. The specs are written and argued over long before the part is actually made, that is the road map. How do you think the datasheets could be automated? The closest to automation, with chip design companies, it to have a set of corporate standards that must be adhered to... The standards include terminology, formats, even fonts. \$\endgroup\$ – R Drast Apr 29 '15 at 15:01
  • \$\begingroup\$ I suppose the other scenario that keeps popping into my head is them using something similar to doxygen or javadoc but for hardware. \$\endgroup\$ – Grit Apr 29 '15 at 15:11
  • 7
    \$\begingroup\$ In Russia our IC manufacturers have decided this problem via the most simple way: they don't write datasheets at all. \$\endgroup\$ – Alexander Perechnev Apr 29 '15 at 16:03
  • \$\begingroup\$ Remember the datasheet is the tip of a much larger iceberg of internal project documentation that specifies how the thing works internally. Almost all of that is Word documents. \$\endgroup\$ – pjc50 Apr 29 '15 at 16:09
  • 1
    \$\begingroup\$ @RDrast Cadence and Mentor both offer tools that "automate" datasheet generation by extracting data from simulations. These are pretty useless in my experience but I saw one in action at a sales call a few years ago. It would be good for specifying an op amp or LDO but nothing complex or really custom. I suspect Grit is a student and saw this type of tool in school and thought it was standard practice. \$\endgroup\$ – crgrace Apr 29 '15 at 16:12
8
\$\begingroup\$

I work for a large IC manufacturer and we do have a separate department that handles the generation of the published versions of datasheets. This department is in charge of making sure that the datasheet has proper English, uses the correct industry and company terminology, complies with the company's formatting standards, doesn't contain any text that would have bad legal implications for the company, etc. The document is XML-based.

Before that department gets involved, the engineer in charge of the product's specifications (usually called a "systems engineer" or similar) maintains the datasheet. The initial datasheet is usually based on a previous-generation product, so much of the information has already been generated. Throughout the development process, the systems engineer updates the specifications based on inputs from the other development engineers (all the development engineers can read the document from a central repository, but only the systems engineer can write to it). In the course of these updates, plenty of engineers get a chance to correct technical as well as spelling/grammatical errors (because they're reviewing the datasheet for their own work anyway). These engineers also provide the systems engineer with data to add to the datasheet (e.g. block diagrams, application circuit diagrams, scope captures, etc.). When it's time for release, the development engineers have a final review to make sure all the technical data is correct.

At this point, the publishing department gets involved. The publishing department has no idea whether or not the technical details are correct -- their purpose is to ensure the correctness of the formatting, spelling, etc. There's some back and forth between the publishing department and the systems engineer as both sides ensure the final draft is both technically correct as well as formatted correctly.

To summarize the main points:

  • Datasheets are based on the datasheets from previous-generation products (or at least similar products), so they aren't created completely from scratch.
  • All the engineers in the development team read and contribute to the datasheet, but actual editing of the datasheet is controlled by one engineer (the systems engineer).
  • The development team is responsible for ensuring the datasheet is technically accurate.
  • A separate department handles the formatting, terminology, etc.
\$\endgroup\$
  • \$\begingroup\$ Sounds like this works pretty well. \$\endgroup\$ – Grit Apr 29 '15 at 20:50
  • \$\begingroup\$ My previous comment was cut short. What I gather from this and the other answers is that having time, well defined roles, and someone to enforce standards are key. And It especially helps to have previous documents and design blocks to work from. \$\endgroup\$ – Grit Apr 29 '15 at 20:59
8
\$\begingroup\$

It depends very much on company culture, as The Photon implied. In some companies the designer(s) is/are responsible for the datasheet. In others it is an Applications Engineer. I can only tell you my personal experience. The take away is datasheet development really informal.

For chips I've been lead engineer for, I've written the datasheet myself using Word. The first draft of the datasheet is often the first part of the Microarchitecture Specification (MAS) which is written early in the design process. In big companies, as Null said, this is driven by the Systems Engineer. Where I work, the designer is usually responsible (and takes on many of the roles of a systems engineer). After the design is finalized, the chip is taped out, and I'm waiting for wafers, I will take the beginning of the MAS and then turn it into a preliminary datasheet. All the text is written, and simulations are put in for all the plots. This is passed around the group for feedback.

Then, the chips come back and the Product Engineer does bringup. The Test Engineer starts measurements and I replace all the simulations with measured data. I also replace the specifications table with real measured data (sometimes specs change after the chip comes back, you know!).

Then, when I deem it complete, I send it to our technical writer (we only have a few where I work) and he or she puts it in the standard form.

As The Photon said, during the design process a lot of ad hoc procedures are used. I used to use Excel for keeping track of pads and signals, now I use Google Docs. The actual DESIGN data, however, is kept in specialized databases accessed by expensive CAD tools with version control and so on.

\$\endgroup\$
  • \$\begingroup\$ Good point about apps engineering involvement. I basically skipped over that, but we do have marketing/apps involved to decide what parts of the internal spec are actually published in the external spec (data sheet). \$\endgroup\$ – The Photon Apr 29 '15 at 16:24
  • \$\begingroup\$ Years ago, I saw a job description by Microchip where they were specifically looking for engineers to both perform testing of new chips and then write the datasheets for them. \$\endgroup\$ – tcrosley Apr 29 '15 at 21:23
5
\$\begingroup\$

At places I've worked engineers pass around Word documents during product development. We usually call that a "target data sheet". Then a tech writer reformats everything nicely, fixes grammar, re-draws diagrams, etc., to produce a customer-ready document.

Are these companies big enough that they can afford to have departments that churn out custom software, databases, etc. to assist their design process?

A good tech writer can do a lot with Framemaker.

And it doesn't really take a custom database to keep track of the functions of 1000 pins or 1000 registers. That kind of thing can be doen with Excel or even Word.

I'm very curious because I'm finding it very hard to keep data/information/specifications uniform throughout the design process.

It's helpful to keep just one "master" copy of the target datasheet. Historically in places I worked the project's tech lead kept it on their desktop. Nowadays we use a cloud site with collaboration tools so that any team member can read or (possibly) edit the up-to-date document at any time.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.