Re: Documenting microprocessors

[George Mena <George -dot- Mena -at- ESSTECH -dot- COM>]

Before application notes, data sheets and product briefs can be
developed for semiconductors in general and microprocessors in
particular, the hardware engineering specification has to exist in
printed form.  Ideally, the engineering team writes this type of
documentation, though some teams have been known to hand over copies of
the engineering data to a TW, but only if they feel *really* comfortable
with him knowing what to put in the engineering spec and what *not* to
put in the data sheet.

The hardware engineering spec details at a minimum:

* the principal analog and digital subsystems
* the on-chip memory architecture
* device timing characteristics such as data setup and hold times,
memory reads and writes and PCI bus timing (both in tabular form and in
signal wave form)
* device electrical characteristics (operating temperature, storage
temperature, operating voltage and more)
* data transfer handling methods such as distributed DMA and transparent
DMA accesses
* any device power-down modes supported as required by the ACPI and
Mobile Power Guidelines '99 specs
* test modes conducted by test plans documented internally by the
company
* all device registers and their default values down to the bit level
* device pinout diagram and matching signal chart (Pin 1 = VDD, for
example)
* device package outline (144-pin thin flat quad pack (TQFP), for
example) and dimensions

Application notes discuss usage of the device in different environments,
how to optimize the device for different applications and more.
Document size varies between 1 to 20 pages typically, depending on the
subject matter being discussed.

Data sheets are scaled down versions of the engineering spec.  Basic
functionality, device architecture and characteristics are discussed,
but not necessarily in great length.  Document size varies between 20 to
200 pages, depending on device complexity.

Product briefs typically feature a summary of device features, including
device electrical characteristics, package outline and dimensions,
functional block diagram, device pinout and matching signal chart.
About a 4-page document.

Next generation product development typically involves different pin
wire bonding schemes, adding or deleting registers, changing the
register locations and default bit settings and other black magic
practiced by the design team.  The writer needs to know what registers
went away, what registers showed up, changes in the pinouts and timing
characteristics -- not much, in other words.  Same silicon, different
configurations.

The big challenge for the writer in a startup environment is to know
when samples come back and when first tapeout is.  These are production
issues that will be driving the documentation efforts.  Expect rapid and
short documentation development cycles, especially if the chip company
is considered to be "fabless" (meaning it's entered into an agreement
with an offshore foundry that's signed a non-disclosure agreement.  The
foundry pounds the silicon out for its customer.  In turn, the company
tests the product to see if it works the way they designed it to work.
Iron out the bugs and get it done in time for tapeout and ramp-up to
full production.

As the writer, be sure you know what the production schedule is and
interact with the design and test engineers and with the marketing folks
as much as possible to meet the deadline.  Don't forget to center
yourself regularly via slow, deep breathing and counting to 10.  Relax
so that the stress doesn't drive you nuts -- because it will.

George Mena

> -----Original Message-----
> From: Patricia Johnson [SMTP:patricia -dot- johnson -at- CPORTCORP -dot- COM]
> Sent: Friday, July 31, 1998 10:15 AM
> To:   TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject:      Documenting microprocessors
>
> My company, a startup, is developing microprocessors. My documentation
> experience has been focused on documenting an end product, not a
> product
> that is implemented into another company's product.
        [George Mena]  snip

> - how does the documentation cycle change to support a microprocessor
> type
> of product?
> - if you rely heavily on development specs as your source material
> (i.e.,
> at least 80% of spec will be in the documentation), then how do you
> make
> the transition from spec to documentation?
> - what type of documents do you write for your audience (with a brief
> description of general content of documents)?
> - how do you deliver the documentation to the customers?
> - anything else you think might be helpful!
>
>