[SI-LIST] Re: Hyperlynx vs. Signal Explorer

  • From: "Peterson, James F \(EHCOE\)" <james.f.peterson@xxxxxxxxxxxxx>
  • To: <si-list@xxxxxxxxxxxxx>
  • Date: Sat, 13 Jan 2007 05:18:54 -0600

 Scott,
You say below "some problems need to be solved at the design level and
by visual inspection" then you mention "thousands of nets".
I'm starting to agree that post-route analysis is not going to give 100%
confidence in the design (especially with 100ps margins and return path
issues), but if I have thousands of nets, then it seems to be a better
level of verification than just visual inspection. 
not perfect, i agree, but still very much needed.

By the way, I will be looking for more info on this challenge at this
year's DesignCon.

Thanks,
Jim


-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Scott McMorrow
Sent: Friday, January 12, 2007 4:03 PM
To: Aubrey_Sparkman@xxxxxxxx
Cc: kwillis@xxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Hyperlynx vs. Signal Explorer

Aubrey,
I wish it were that easy.  Some problems just need to be solved at the
design level and by visual inspection at this time.  There is not enough
compute power available to fully scan for something like return path
issues across thousands of nets.  But, if you've blown the design for
some reason at layout, you're in deep trouble. 

I just want to point out that full board SI doesn't give 100% confidence
in a design, especially at higher and higher bus speeds.

regards,

scott

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed(r) is the registered service mark of Teraspeed Consulting
Group LLC



Aubrey_Sparkman@xxxxxxxx wrote:
> Scott,
> Is this an appropriate rephrase what you've said?  Such a post route 
> analysis would be incomplete and a very conservative person would do 
> more than one type of post route analysis using several different 
> tools.....
>
>
> Aubrey Sparkman
> Enterprise Engineering Signal Integrity Team Dell, Inc.
> Aubrey_Sparkman@xxxxxxxx
> (512) 723-3592
>
> The Greatest Pleasure in Life is Doing what People say can't be
done...
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx 
> [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Scott McMorrow
> Sent: Friday, January 12, 2007 9:33 AM
> To: kwillis@xxxxxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Hyperlynx vs. Signal Explorer
>
> Ken
>
> You're assuming a system that does not have power system resonances, 
> device packaging issues, or return path issues.  In those cases, post 
> layout analysis with most tools provides zero direction.
>
> I do agree that post-layout analysis is valuable for identifying 
> layout mistakes, such as you have stated.  But, in modern buses, the 
> value in finding the worst of problems is diminishing, especially when

> timing margins are in the sub 100ps level, and voltage margins are in 
> the 50 mV region.
>
> regards,
>
> Scott
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>
> http://www.teraspeed.com
>
> Teraspeed(r) is the registered service mark of Teraspeed Consulting 
> Group LLC
>
>
>
> Ken Willis wrote:
>   
>> 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
>>   
>>
>>   
>>     
> ------------------------------------------------------------------
> 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
>   
>
>   


------------------------------------------------------------------
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
  

------------------------------------------------------------------
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: