From: Scott McMorrow ([email protected])
Date: Mon Feb 21 2000 - 12:08:58 PST
Roy,
Good questions!
Roy Leventhal wrote:
> Scott,
>
> I read your reply with a great amount of interest an a predisposition to the
> same point of view. But, since you can quote from before/after experience and I
> cannot, what are your observations on time-to-market of the two methods
> (rules-based Vs simulation-based)? Particularly:
>
> 1. Early in coming up the learning curve of making simulation an intregal part
> of the design process Vs later when you understand what to do in detail?
>
Here is a set of examples from my experience at the same company. The
product line was OEM SHV (standard high volume) server motherboards.
Project A - A Pentium dual-processor board laid out without regard to signal
integrity concerns where signal integrity simulation was a 1-week line
item in the schedule to which I was assigned. It was Fab-4 until we had
a board which worked well enough to develop BIO code on. At each board
spin I requested additional time to perform in-depth signal integrity analysis
on all sub-systems and was told that there was not enough time in the
schedule. This particular board went to Fab-8 before it was stable enough
for high volume production ... and over 6 months late to market.
Project B - A P6 dual-processor server with seperate processor/memory
module. Full signal integrity simulation was performed pre-route and
post-route on all signals by 4 signal integrity engineers concurrently with
logic design and layout. Two different well known signal integrity simulation
tools were used on the project, one of which was mature, the other of which
was immature. Project schedule was extremely aggressive with an 8 week
design to tapeout cycle. Tapeout proved to be 1 day late (on Christmas Eve).
No signal integrity or timing problems were ever discovered in either
board. A connector pin mirroring issue kept the first Fab from being 100%
functional and kept us up in the model shop all night on the weekend
fabricating a connector that would plug into the back of the board. Within
2 days of power on the board set worked at speed. Within 2 weeks all
major multiprocessor X86 operating systems were operational.
Server software engineering became the critical path in the project and
cause over a 3 month total schedule slip. This product won numerous
industry awards for our OEM customers.
Projects N and R - Two PII, PIII single and dual processor server motherboards.
Full signal integrity performed by (now accomplished) signal integrity
engineers who had become more efficient. Both projects were completed
on time and within 2 Fabs. No signal integrity problems on either board.
Products met all marketing requirements and were released to production
late due to slippages in server software engineering schedules. Both
products are still in production at high run rates.
Project L - Key signal integrity engineers left. SI engineering was ignored
in design phase and considered to be unimportant by management.
Designs were just "cut and pastes" from previous designs of same and
other groups at the company. Project was perpetually behind schedule
due to signal integrity and EMI issues. Multiple board fabs were required
after the fact (5 I believe) to fix all issues before production.
Project T - A different company. After multiple signal integrity consulting
engagements with the company we had produced 10 boards with
no more than 2 Fab turns prior to production with no signal integrity
or EMI issues. Many engineers were trained in basic signal integrity
principals and became "scared straight". Several engineers were
trained in use of tools. One became reasonably proficient in SI tool
usage to the point of performing preliminary analysis on critical nets, making
informed design decisions and performing post-layout analysis. Within
one year a signal integrity engineer had been born. In conjunction with
her abilities and our own consulting this company has not had a
signal integrity failure on any board in a very complex 10 board
system. Management at this company has totally embraced signal
integrity engineering on all boards and made the following comment:
" Before we incorporated signal integrity analysis into our design flow
we were afraid to make logic and feature changes to our boards for
fear that some signal integrity issue would turn up and break them. Now
we can respond to our market requirements, make feature set and
design changes, perform signal integrity analysis, and tape out to
Fab in 2 or 3 weeks."
This company is currently ahead of all hardware engineering schedules
that they set. Software engineering is now on the critical path.
>
> 2. On projects where you are looking to produce a board with reduced
> functionality as early as possible Vs full functionality later?
>
I have a very basic rule of thumb here:
"The software engineering department should always be placed
on the critical path."
How do we do this? We guarantee
good signal integrity even in reduced functionality boards. Sometimes by
brute force and over-engineering. Logic errors are easy to debug. Critical
timing for reduced functionality can be guaranteed by signal integrity and timing
simulations up front. Margin is a very good thing!!!!! If the signal integrity
is comprimised in quick turn boards we end up with debug nightmares. My
experience has shown that the evil software engineering department manager
(just imagine a Dilbert cartoon) will use any hardware problem as an excuse
for slipping schedule and blame it on hardware engineering.
I advocate full board crosstalk checks and the subsequent rerouting effort
to eliminate the most hideous of problems. I have seen way too many board
fail due to reset on "non-critical" reset lines or data pattern dependent
errors. I find that even if I cannot correctly model all parts in the design that if
I assume the driver strength and edge rates of FCT, LVC ... etc. (extremely
fast strong drivers) I can ensure that there are no hidden crosstalk problems
in the design. This is especially important when auto routers are used in
layout. CCT has a very simple prime directive. " Thou shalt place all
copper down on the board and make all connections regardless of design
rules." This often means that an auto router will break specific layer
bias rules in order to make the final connections on a board. When there
are parallel routing layers which are not seperated by a power plane
(an unfortunate artifact of high volume, low cost designs) then it is highly
probable and always likely that there are huge crosstalk issues which are
nearly impossible to debug without simulation help.
These "quick and dirty" crosstalk checks will find a multitude of sins.
I also advocate "quick and dirty" overshoot, undershoot and timing
checks before tapeout of quick turn reduced functionality boards, also.
>
> 3. What are your views of the combining the best of rules-based design plus
> simulation-based design?
I think this is the best of both worlds since it balances efficiencies in both areas.
Like all engineers I use rules of thumb to place terminators, to determine what
the most likely topology will be for a particular network structures. Often we cannot
perform the ideal signal integrity analysis pre-layout. Schedule and market constraints
always work against good engineering. So rules of thumb, SWAGs, and WAGs
are always important to apply. When an engineer with experience applys them
the chances are the 99% of the time the result will be close to correct. If then
post layout simlulation is performed by the same engineer there is an extremelly
good check for correctness.
Unfortunately, a little knowledge can be extremely dangerous. Rules of thumb
in the wrong hands, or in the hands of the partially educated can be very dangerous.
You would be surprised at the number of designs I still see with series, parallel
and ac termination placed on the same net within a design, since the
"rule of thumb" was to put it down on the board and "tune" the termination in the
lab. Sad but true!
best regards,
scott
-- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com**** To unsubscribe from si-list or si-list-digest: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu ****
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:35:07 PDT