[SI-LIST] Re: Hyperlynx vs. Signal Explorer
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Fri, 12 Jan 2007 10:19:12 -0500
Hi,
This has been an interesting thread. I have had similar experiences with
xtalk as
mentioned by Ned. A top-down methodology, with pre-route SI and
constraint-driven
layout, is a nice primary approach and a good place to invest most of
your focus.
But unless you characterize 100% of all the different classes of signals
in your
design to the nth degree, there will be some aspects that will probably
fall
through the cracks in your cns-driven layout. And if you did constrain
everything
in 100% detail, you may have taken too long to get into layout, or will
take too
long to complete the routing.
And you may even find some goof-ups, like the constraint said to put the
terminator
at the wrong end of the net, or some signal deemed up front to be
"non-critical" ended
up being routed 6 inches to an unpopulated test header, making it ring
like crazy. If
you can make the post-route SI essentially a "check mark" that doesn't
add weeks to
your schedule, I have found it to be a good backstop to have.
The other thing I have found to be beneficial is to partner up with the
layout
designer, if they have a lot of experience, and do some "incremental"
post-route
analysis. Sometimes on a really dense design, they may be able to see
the way to
pull off the routing in the most efficient way (or the only practical
way), and
running post-route on their initial attempt may show that their approach
is a good
way to go on that design. Sometimes that ends up being faster than
exhaustive up-
front characterization. As always, there are trade-offs.
Another place the post-route really helps that I haven't seen mentioned
yet is the
benefit it can have for hardware verification in the lab. From the
post-route SI
analysis, you can determine the bit of the bus with the smallest margin,
and go
directly to that signal in the lab when the boards come in from fab. It
can save
a lot of time on the hardware verification if you have the confidence to
pre-screen
the worst signals out with your post-route analysis, and prioritize them
to be
reviewed first. And it is really nice to have the laptop sitting on the
lab bench
with you for troubleshooting. You can quickly resolve things like when
the wrong
drivers have been programmed into your FPGA, or be able to quickly look
at some
signals that may simply be inaccesible for probing in your system (ex.
mezzanine
cards), or investigate some other funky things you see in the
measurements by
extracting topologies, etc.
Ken Willis
Cadence Design Systems
(860) 871-7070
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Dempsher, Ned @ CSE
Sent: Friday, January 12, 2007 8:07 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Hyperlynx vs. Signal Explorer
Hi SI-LIST,
I would like to contribute a point on this issue which has particular
bearing for our designs here at L-3 Communications.
Post route simulation is a must here for us to, among other things, fix
crosstalk problems.
The problem with establishing realistic parallelism rules is that you
need to assume a certain number of aggressors on your nets, a particular
aggressor driver type (various edge rate & amplitude), a particular
receiver noise margin and a certain aggressor-victim topology (where the
receiver is in relation to the driver). Variations on any of these
parameters can have a drastic effect on how close and how long you are
permitted to route near a victim net.=3D20
It is not unusual for us to employ a wide variety of driver-receiver
types (PECL, LVDS, SSTL, HSTL, 1.8v LVCMOS, 2.5 LVCMOS, 3.3 LVTTL and
even, occasionally, 5 volt logic) within one design which cannot be
segregated from one another due to form factor constraints. Many of
these PCBs are double sided/packed with multiple 1000+ ball FPGAs. We
have great difficulties even routing these boards let alone meeting
spacing requirements.
To provide a comprehensive list of parallelism rules for all of these
cases would be extremely complicated and overwhelm our CAD folks.=3D20
Assuming a worst case number of aggressors, driver amplitude/edge,
topology, and receiver noise margin will create an unrealistic rule set
which cannot be implemented.
Assuming a realistic number of aggressors (2) and typical edge
rate/amplitudes when generating spacing/parallelism rules will catch
most of your problems but not all.=3D20
We have found it more efficient to provide a relatively loose simple
rule set to CAD which will catch 80-90% of the problems and then rely on
post-route simulation to catch the rest.
Certainly many PCBs are successfully built without post-route
simulation. It just provides a little added insurance.
Hope this helps,
Ned Dempsher
L-3 Communications
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Todd Westerhoff
Sent: Thursday, January 11, 2007 6:53 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Hyperlynx vs. Signal Explorer
Chris,
I agree with your point, in theory. In practice, however, I have found
post-route simulation to be useful. The trick is - post-route analysis
shouldn't become an end to itself. It should be a logical (and
efficient)
extension of your pre-route work.
In theory, you can do you your pre-route studies and tell the PCB
designers what you want. If they design to those rules, you should have
no problems.
However, what usually happens is that your initial pre-route studies are
based on an estimate of how the board will be routed, and the PCB
designer comes back to you halfway through routing and tells you they
can't meet the match length requirements because one of the other
components just got moved and now interferes with the routing path, or
the terminators had to be moved to make room for the decoupling caps, or
whatever. My point is - you almost never get a board routed with your
first set of rules - the design process iterates.
This is not necessarily a big deal. If you're organized, you can
quickly update your pre-route studies to accommodate the change, run the
simulations and determine what impact they have on interface timing.
You'll then know if you can afford the hit, or if you need to change
your routing rules, which require another round of simulations and
timing analysis. At some point, you'll either have updated rules, be
willing to live with the margins you've got, or have one of those famous
discussions with the project manager (at which point having your
analytical ducks in order is definitely advised).
I believe that high speed design is a triad involving timing analysis,
signal integrity and design decisions/rules (By 'decisions', I mean
things like "do we use termination, what values, and where", and by
'rules', I mean things like pin ordering, stub lengths & lengths/length
matching).
Changing
any leg of the triad impacts the others, typically requires re-analysis
and may/may not require a shift in the design strategy. I maintain that
high speed design is iterative and having a good process for quickly
"turning the crank" when there is a change in the timing model/signal
integrity/physical design is a key to success. Knowing your experience
level, I'm sure you're quite good at this.
Here's my point - if it were possible to take the work you've done in
setting up your pre-route analysis, and quickly & easily leverage that
to perform post-route SI & timing, I'd expect you wouldn't have strong
objections. If it cost you nothing other than computer time (and not
weeks of it), you'd probably run it to see what would happen ... and you
might find (as others have) that the routing variations in the actual
board didn't fall quite the way you expected, that your clocks are quite
as centered as you thought they would be, and there's some margin to be
had, even if only a little bit, by moving your clocks.
There's a premise here - it's only worth it if post-route analysis
doesn't become a project unto itself. It shouldn't be a big, separate,
deal - it should be a natural (and automated) extension of your
pre-route work.
That's not necessarily easy (and highly tool dependent) - but, in my
experience, it's been worth it.
My $0.015.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at: =3D20
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
=3D20
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at: =20
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
=20
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
