The importance of Design Rules

This started with an aside in "Crypto", Stephen Levy (2000), about Rivest's first attempt at creating an RSA Crypto chip failing because whilst the design worked perfectly on the simulator, it didn't work when fabricated.
[p134] Alderman blames the failure on their overreliance on Carver Mead's publications...
Carver Mead and Lynn Conway at CalTech revolutionised VLSI design and production around 1980, publishing "Introduction to VLSI System Design" and providing access to fabrication lines for students and academics. This has been widely written about:
e.g. in "The Power of Modularity", a short piece on the birth of the microchip from Longview Institute, and a 2007 Computerworld piece on the importance of Mead and Conway's work.

David A. Patterson wrote of a further, related, effect in Scientific American, September 1995, p63, "Microprocessors in 2020"

Every 18 months microprocessors double in speed. Within 25 years, one computer will be as powerful as all those in Silicon Valley today

Most recently, microprocessors have become more powerful, thanks to a change in the design approach.
Following the lead of researchers at universities and laboratories across the U.S., commercial chip designers now take a quantitative approach to computer architecture.
Careful experiments precede hardware development, and engineers use sensible metrics to judge their success.
Computer companies acted in concert to adopt this design strategy during the 1980s, and as a result, the rate of improvement in microprocessor technology has risen from 35 percent a year only a decade ago to its current high of approximately 55 percent a year, or almost 4 percent each month.
Processors are now three times faster than had been predicted in the early 1980s;
it is as if our wish was granted, and we now have machines from the year 2000.
Copyright 1995 Scientific American, Inc.
The important points are:
  • These acts, capturing expert knowledge in formal Design Rules, were intentional and deliberate.
  • These rules weren't an arbitrary collection just thrown together, they were a three-part approach, 1) the dimensionless scalable design rules, 2) the partitioning of tasks and 3) system integration and testing activities.
  • The impact, through a compounding rate effect, has been immense e.g. through Moore's Law doubling time, bringing CPU improvements forward 20 years.
  • The Design Rules have become embedded in software design and simulation tools, allowing new silicon devices to be designed much faster, with more complexity and with orders fewer errors and faults.
  • It's a very successful model that's been replicated in other areas of I.T.
So I'm wondering why vendors don't push this model in other areas?
Does it not work, not scale or is not considered 'useful' or 'necessary'?

There are some tools that contain embedded expert knowledge, e.g. for server storage configuration. But they are tightly tied to particular vendors and product families.

Update 13-Nov-2011: What makes/defines a Design Rule (DR)?

Design Rules fall in the middle ground between  "Rules-of-Thumb" used in Art/Craft of Practice and  the authoritative, abstract models/equations of Science.

They define the middle ground  of Engineering:
 more formal than R-o-T's but more general and directly applicable than the theories models and equations of pure Science, suitable for creating and costing Engineering designs.

This "The Design Rule for I.T./Computing" approach is modelled after the VLSI technique used for many decades, but is not a slavish derivation of it.

Every well understood field of Engineering has one definitive/authoritative "XXX Engineering Handbook" publication that covers all the sub-fields/specialities, recites all the formal Knowledge, Equations, Models, Relationships and Techniques, provides Case Studies, Tutorials, necessary Tables/Charts and worked examples. Plus basic material of ancillary, related or supporting fields.

The object of these "Engineering Handbooks" is that any capable, competent, certified Engineer in a field can rely on its material to solve problems, projects or designs that come their way. They have a reference they can rely upon for their field.

Quantifying specific costs and materials/constraints comes from vendor/product specifications and contracts or price lists. These numbers are used for the detailed calculations and pricing using the techniques/models/equations given in The Engineering Handbook.

A collection  of "Design Rules for I.T. and Computing" may serve the same need.

What are the requirements of a DR?:
  • Explicitly list aspects covered and not covered by the DR:
     eg. Persistent Data Storage vs Permanent Archival Storage
  • Constraints and Limits of the DR:
    What's the largest, smallest or complex system applicable.
  • Complete: all Engineering factors named and quantified.
  • Inputs and Outputs: Power, Heat, Air/Water, ...
  • Scalable: How to scale the DR up and down.
  • Accounting costs: Whole of Life, CapEx and Opex models.
  • Environmental Requirements: 
  • Availability and Serviceability:
  • Contamination/Pollution: Production, Supply and Operation.
  • Waste generation and disposal.
  • Consumables, Maintenance, Operation and Administration
  • Training, Staffing, User education.
  • Deployment, Installation/Cutover, Removal/Replacement.
  • Compatibility with systems, components and people.
  • Optimisable in multiple dimensions.  Covers all the aspects traded off in Engineering decisions:
    • Cost: per unit, 'specific metric' (eg $$/Gb),
    • Speed/Performance:  how it's defined, measured, reported and compared.
    • 'Space' (Speed and 'Space' in the sense of Algorithmn trade-off)
    • Size, Weight, and other Physical characteristics
    • 'Quality' (of design and execution, not the simplistic "fault/error rate")
    • Product compliance to specification, repeatability of 'performance'. (manufacturing defects, variance, problems, ...)
    • Usability
    • Safety/Security
    • Reliability/Recovery
  • other factors will be needed to achieve a model/rule that is:
     {Correct, Consistent, Complete, Canonical (ie min size)}


Neil Gunther said...

I'm not sure I understand what you're getting at here. Are talking about VLSI tools or (CAD) tools more generally?

Regarding Mead/Conway, Conway was at Xerox PARC (not Caltech) and we did use M/C DRs for fabbing chips. The λ-based scaling rules were originally for NMOS and worked well. However, we did run into serious trouble when we went to CMOS because of things like "latch up" effects. I know because I had to write the code to test the parametrics.

I lost track after 1990, but I would assume the solution of thicker oxide wells was embedded into CAD tools with newer CMOS DRs.

The next big frontier that I'm aware of is getting to sub 90nm geometries. That required going to Hf gates and all sorts of other tweaks to avoid leakage. One assumes all that is now embedded in CAD tools with even newer CMOS design rules, because we are now down to 22nm designs.

Of course, there's still the capacitive heating problem which can't be DR-ed away (hence multicores).

Another thing to keep in mind is that, unlike M/C, DRs are usually proprietary crown jewels in the highly competitive VLSI industry.

For non-VLSI, I've already described prototype DRs for quantum communication devices:
1. SPIE News
2. HP Labs Tech Report.

More generally still, one could argue that tools like Mathematica embed known "design" rules; albeit not DRs in the usual eng sense.

SteveJ said...
This comment has been removed by the author.
SteveJ said...

n answer to "What am I talking about?". Not the specifics of "VLSI or CAD", but the concept in General as applied to Engineering.

In computing/I.T., there's no guidelines/rules of the 'art' of putting together systems according to a criteria (min. cost, max space, 'balanced', hi-perf, max perf).

I believe that for at least some sub-systems (eg. Storage), that real Design Rules are possible (the type that can be formulated in a spreadsheet with costs/constraints added).

They may not be as elegant as Mead/Conway "Dimensionless Scalable" DR's, but at least we can attempt to formalise what is known and see if better quality/more genearl rules can be developed. It's the sort of guidance you'd hope vendors would give.

It's why 8mm helical-scan tapes for data aren't sold anymore. Optical disks are {cheaper, better, faster, larger}, as are USB drives/Memory sticks for smaller tasks.

Neil Gunther said...

At the IT/data center system level, I'm fairly certain people do use spredsheets, and similations in some cases. But it's all roll-your-own.

Once again proprietary interests weigh heavily here. It's one way to reduce costs relative to your competitor.

FB has gone counter to this in some respects with their open d/c spec, but only up to a point, I'd wager.

And forget about the vendors actively fostering such things as d/c DRs. The last thing they want is to have their dirty "power" or performance laundry aired in public.

Heteorgeneity of vendor offerings is another problem for producing coherent DRs.

At the same time, a lot of aspects of d/c IT are becoming more and more modularized, e.g., d/c in a crate. And that really means any DR options that you might've had are gradually being taken away from you. (cf. SMP vs multicore black box) Ultimately, like a modern car, when a component fails, you just replace the entire module or buy a different car.