Finding the included Design errors

Design errors, included?

Finding the included Design errors

In the last article “If I had only known! I would have ….” I’ve showed you some functionality of Hyperlynx DRC using three of the 23 rules.  And I ended my article by asking:
 

  • Where does the information come from?
  • What extra data does HyperLynx DRC need, in order to interpret my data correctly?
  • What is the extra workload?

 

To answer these questions it’s best to breakdown in three parts.

 

1. The Startup wizard

When starting your design the first time, the wizard pops up automatically and guides you through the minimal required settings.

 
  • Configuration of your environment:

Such as units ans default values. It even allows the user to set a project specific directory structure to find available models and set project dedicated settings.

  • Additional classification criteria.

Provides the option to overrule or add component classifications into the database objects based on criteria like reference designator prefix. (In my design connector starts with X, see picture)

  • Electrical information

Components (connectors, beads, etc.)

  • Field-solver accuracy

Setting items like coupling criteria, min aria size and self-coupling.


 

The startup wizard is pretty complete but it will only take you a few minutes and you can store and recall it from previous sessions or re-invoke it on an existing design.

 

2. Object classes which make the rule Intelligent

In article 2 I promised you that the HyperLynx DRC application “Can analyze the design data in a way that is similar to your interpretation of the design”. To show you how this is possible I will use the three examples again. This will show how the objects can be used to perform an analysis smart, easy and quick.

 

2A: Electrical (Vertical Reference Plane Change)

Remember, this is how your list of problems was displayed.
 


HyperLynx DRC notices three items here.
 

Electrical

Recognition of the Power signals, therefore it has 2 Object collections

Ground Nets

 

 

Power Nets

 

 

Electrical

 

   


Fieldsolver

Recognition of the coupling into what Plain, see screenshot above.
 

Intelligent board info, component information

Detection of a “Via” between plains and a “Coupling Capacitor” between the detected constant nets.


And the objects on itself are coupled as well. For example:

  • A net turns into a constant net which, in combination with copper aria, turns into a plane.
  • A component of the object capacitor, connected between two constant nets, turns into a decoupling capacitor.

 

This example shows how connecting the object let the application interpret your design in an intelligent manner. Actually, in a similar way as you would have done it.

 

2B. Mechanical Filter Placement

With this rule within HyperLynx DRC there are a few other things to point out. This is how your list of problems is displayed.
 

The list of objects involved have been received from the rule parameter information sheet.
   
  • Object classification (Connectors, which results in i/o nets requiring a filter)

 

HyperLynx DRC recognizes connectors as an object, and thereby all nets connected to it. (See the wizard where I added X as reference prefix)

 
  • Other classifications (cq: Noise filter)

This object is a combination from Ferrite Beads and Inductors.

 

The pictures below show you can add any other type to this list, and also that the inductor is based on its reference prefix and number of pins.
 


The examples showed how easy object classification are modified to your company standards and how to nest earlier defined object to new/combined objects.

 

2C. IO Coupling

With this rule I would like to show you how easy it is to change testing conditions on-the-fly and manually explore your design with the information the system has collected. This is how your problem with the default value (500 Mil) is displayed.
 

 

But what if: The “MaxRunLength” parameter changes from 500 to 250 Mil?
 


This rule uses the following information which can be further explored with some options within the application:
 

  • Intelligent board information, component information. The HyperLynx DRC application recognizes connectors as an object.
  • Recognizing the electrical net and its coupling:
   

First a capacitor is recognized. HF-current flows through a capacitor, so two physical nets become one electrical net. The electrical net will be analyzed for coupling. The application can mark all the coupled segments on the electrical net (blue segments in the picture). How? I just clicked the net (green) and enabled the coupling options in the toolbar (as indicated by the blue circles).

In general one can say: HyperLynx DRC has many methods to enable a detailed investigation of the problem using the objects known.

 

Conclusion:

The three examples showed you how the HyperLynx DRC application automatically creates object classes, the design can be interpreted with the intelligence stored in the objects and classes. After tuning the rules, by setting the existing objects criteria’s, you can retrieve the desired information in such a way that the violation is revealed. You can even add your own object to the object list. This brings us to part 3:  Writing your own rules

 

3. Introduction in writing your own rules

The challenging part is to make the rule definition and map it to the objects you need. The HyperLynx DRC application provides a very large number of objects and classes that you can use. Once this is done, you can start creating the rule via the below described 4-steps procedure:
 

Step 1

Choose: make a new rule

 

   

Step 2

Fill in the required fields

Besides name and other obvious fields there are three important fields:

  • Location
  • Script file
  • Documentation
   

Step 3

tart with the rule template provided.

Click the right mouse button, and choose: ‘the rule end select option edit’. Your script becomes visible in the “Script Debugger” window.
 


Step 4

Rule writing: start with defining the rule parameter, then reported error attributes, (see picture above) followed by the rule code itself.

 

To finish the rule, two other things are required:

  • Rule documentation:

Pointers to screen shots, require manual editing of the Template document HTML file. And generation of these files can be done by many software tools. I prefer PPT (see the yellow marked pointers below).
 

 

  • Rule actions reporting:

This is the last part and  a program by itself. It describes what to do when you investigate the reported violation. In the rules violation declaration you refer to an HTML page. This HTML page contains the individual action shown in the violation “detail window” and then refers to the rule action script. Or in a picture:



It’s a three level sequence. Not that hard but the most difficult part of the principles of rule programing.

 

Summarize

This article started with three questions. And by explaining the Start up wizard, the Object classes and Rule writing, I'm able to answer as follows:
 

Q: Where does the information come from?

A: From the Object classes set during the Setup.

Q: What extra data does HyperLynx DRC need to interpret my data correctly?

A: Correct Configuration of the Object classes

Q: What is the extra workload?

A: Getting familiar with the HyperLynx DRC tool.

 

So now remains the final question: 
 

Does the Hyperlynx DRC tool really work?

Who better to answer this then another user! And this is exactly what the last article in this series will cover.
 

If you’re too curious and cannot wait until the next Newsletter, please contact us via info@innofour.com or give us a call.

 

Would you like to try HyperLynx DRC for yourself?  Register for our HyperLynx DRC workshop on the 4th of November 2014.

This HyperLynx DRC workshop is free of cost, but has limited space.