GCC Error Messages

Building a Parameterized Artwork Macro (PAM) is similar to working in a programming language such as Basic, Pascal, or C, in that there is source code that is compiled into an executable program. In the case of a PAM, the source code is the source layout, comprising shapes to manipulate and controls that perform the manipulation. The source layout is compiled into an executable AEL macro (which is itself a programming language used by the Advanced Design System).

As when you use a programming language, you should never delete the source code. Save the source layout as long as the macro remains in use. If you wish to modify the source layout to create a new macro, copy the design into a new layout.

As with programming languages, these types of errors are possible:

This chapter provides details on these types of errors as they pertain to a PAM.

Syntax Errors

In the context of a PAM, syntax errors are typically errors in equations. For example, the equation length++1 would be a syntax error. Most syntax errors will be trapped in the control dialog when you click OK. At that point, each expression is passed to an AEL parser to check the syntax. Any errors reported by the parser are displayed in a pop-up dialog, and the offending expression is colored red to help you quickly see which one has the error. All syntax errors must be fixed before the control is accepted.

Semantic Errors

Semantic errors are errors in usage. These include trying to do a list index into a variable that is not a list (using the AEL nth() function). These types of errors are not identified by the AEL parser (the syntax is correct) and at this point will not be identified until the parser generates a run-time error (see below).

Logic Errors

Logic errors are errors in the flow of the program. Everything seems correct, the macro runs fine, but it generates the wrong results. These errors may be very hard to find and fix in a complicated macro, which is why a macro should be built from a simple starting case and expanded. If you start with something simple that works, it is much easier to add a little bit more. If it fails, the problem is in what was just added, not in anything that was previously working. There is no easy way to find and fix logic errors. You must understand what you want to do, and what the controls are actually doing.

The example in First Spiral Example illustrates the concept of starting simple and working up to a complicated macro.

Run-Time Errors

In the context of a PAM, run-time errors fall into two classes:

Math Errors

Math errors are typically caused by improper user-input for a parameter. One example is user-input that results in a divide-by-zero in an equation. These errors are trapped by AEL and cause the macro to abort execution.

Another example error would be user-input that causes one of the copy controls (Repeat or Polar) to go into an infinite loop. These errors are trapped by the run-time control code when a loop request exceeds the internal maximum copy limit. Again, if the error occurs the macro execution is aborted. You can set the maximum copy limit using the CELL_COMPILER_MAX_COPY=1000 configuration file option.

Untrapped Semantic Errors

Of all the errors possible, untrapped semantic errors will generate errors that are the most removed from the actual cause. This is best demonstrated by an example:

Defining Repeat Distance as Step

A common mistake is to use the variable name step for the Repeat Distance field in the Repeat control. Because step is a reserved word in AEL, it does not generate a syntax error, but it is also not identified as a user parameter. One of the reasons it is important to check the list of identified parameter names generated by the compile (as well as to check the Design/Parameters dialog box to see what the variables are and what the default values/units are) is that if a parameter is not listed, you may have used an AEL reserved word.

When you try to insert a macro that has been compiled with step as the Repeat Distance, the following error message appears:
(couple_art.ael line 164, column 11 in struct2)
operand real value expected
Cannot load component artwork

Because step returned a value that was not a number, an error was generated when the program tried to evaluate the expression in which it was used. The best way to deal with an error of this type is to edit the PAM script. Go to the line indicated in the error message. Look there (or a few lines above) for something wrong. In this case the generated code has nothing obviously wrong:

decl p_value1X_3 = number;

      decl p_value2X_3 = step;

      decl p_value1Y_3 = 0.0;

      decl p_value2Y_3 = 0.0;

      pam_rep = pam_do_repeat\(

            PAM_COMMON_DATA,        p_416DB340,

            PAM_REPEAT_DIRECTION,   1,

            PAM_REPEAT_MODEX,       3,

            PAM_REPEAT_VALUE1X,     p_value1X_3,

            PAM_REPEAT_VALUE2X,     p_value2X_3,

            PAM_REPEAT_MODEY,       3,

            PAM_REPEAT_VALUE1Y,     p_value1Y_3,

            PAM_REPEAT_VALUE2Y,     p_value2Y_3\);

When this type of error occurs, look at each variable/function name and make sure it is being identified correctly ( step is not, in this case) and that, in the case of intrinsic functions, it is being used properly.

Missing or Incorrect Unit Designators

Another common run-time error is caused by missing or incorrect unit designators in equations. The default MKSA unit for length is meters, but most designers define the Layout window to be in µm or mils. This means that any value without a unit specified is treated as meters.

Example If a Repeat control is defined with a fixed repeat distance of 100 mil, and you forget the mil and just enter 100, the system treats that as a repeat distance of 100 meters. This means that the inserted macro will be very big.

The system makes an effort to trap unit problem by checking for shape data values that exceed the database numeric range. A layout will have a specific layout unit (such as mil) and resolution (0.01, for example) as set in the Options/Preferences dialog under the Layout Units tab. These values will define the maximum size of any data value used in the layout, both in terms of absolute size and number of significant digits.

The system monitors the primitive data looking for values that will overflow when converted to database units. If an overflow is identified, the following error message is displayed:

As the message states, the macro's parameter values as well as any constants used in the control definitions should be checked for missing unit designators. Other things to look for would be various math errors or magnitude errors that results in extremely large numeric values (several orders of magnitude larger than the unit being used).

In addition to the above error checking done by the system, this type of error may have other clues to help you recognize it:

If any of these things happen while you are developing or testing a macro, there is probably a unit mismatch somewhere.

Macro Error Messages

What following section lists the warning and error messages you are likely to encounter when using the Graphical Cell Compiler. The listing provides more detail on each message: what caused the message and what to do to fix it.

The messages are grouped in three sections to parallel the three areas of interaction for macro: definition, compilation, and execution.

Macro Definition Messages

There must be ONE construction line selected as a reference.

Several of the controls (Stretch, Repeat, and Polar) require a construction line to be included as a reference line for the operation. This message indicates that a control definition was completed (the OK button was pressed) but there was more than one construction line selected.

Shapes to be operated on must be selected.

Most of the controls require graphic shapes to be included as the object of the operation (Stretch for example).

This messages indicates that a control definition was completed (the OK button was pressed) but there were no shapes present and selected in the design.

Shapes with width to be operated on must be selected.

The Width control only operates on graphic shapes that support the idea of width. At this time that is a Path. This messages indicates that a control definition was completed (the OK button was pressed) but there were no Paths present and selected in the design.

[field name] Field:

ERROR AELxxxx(column x) [ael error]
This message indicates that there was an AEL syntax error as listed in the specified field for the current dialog. The message will attempt to identify the column number where the error was discovered and list the nature of the error. See the AEL Guide for more information about valid AEL syntax.

[field name] information must be provided.

This message indicates that the named required field must have a value before the control definition is complete.

Macro Compilation Messages

Warning: functions currently undefined:

This warning message indicates that the listed function names were used within the various control expressions, but are not yet defined in the system. This could mean that the function is not a part of AEL or may be mis-spelled. If it's a user-defined function, then it means the file containing the function definition as not yet been loaded into the system.

This warning message has no effect on the compilation of the PAM. If there were no other warning or error messages, the compiled PAM is fine and ready to run. But the listed function must be loaded into the system before the PAM is executed to create the specified artwork. If the function is still not found then a run-time error will be generated.

Identified the model parameters:

This is an informative message only. It lists the undefined variables found in all the control expressions. These variables will be used as the model parameters and will show up in the Design/Parameters dialog.

It's always a good idea to check this list to make sure that all the names you expect show up (you didn't use an AEL reserved word by accident) and that there aren't any extra ones (perhaps due to a spelling error of an AEL name).

Warning: no primitives found for this control

While processing a control it was discovered that there were no primitive shapes associated with it. This typically happens when a control is defined and then the shapes that were selected for it to operate on were deleted. Perhaps a shape was deleted and re-inserted to fix something but the control was not edited to associate the new shape with the control.

Warning: primitives without width ignored for this control

The Width control can only operate on shapes with width (like a path). If a shape without width is included in the control the above warning is displayed.

Warning: detected primitives with different (x,y) point counts for this control.

In most cases the User-Defined control will be written to work with a given class of shapes, polygons for example. It is much more complicated to write one function that can work with a mixture of shape types, for example polygons (which can have three or more points) and text (which has only one (x,y) point). If while compiling the macro it discovers mixed shape types associated with a User-Defined control, the above warning is displayed.

While this may be in fact intended, one should be very careful about passing different shape types to a give user-defined function.

Warning: ignored unsupported graphical primitive type: [name]

If while processing a control it discovers a primitive shape, component, or connectivity element that the control will not support this message is printed. For example, Wires are not supported by any of the controls.

If this warning is displayed even though the Layout appears to not have any unsupported items present, it is probably because the design was not empty to begin with. Perhaps an old design was used (after deleting everything visible) or perhaps there is or was a Schematic page in the design. It's always best to start with a newly created design to be sure there won't be anything left over from previous work.

ERROR: no construction line found for this control

While processing a control it was discovered that there was no construction line associated with it. This typically happens when a control is defined and then the construction line is deleted and re-inserted to modify it's location or angle. The control will need to be edited and a construction line selected to be associated with it.

Compile complete:

errors =
warnings =
This is simply a summary message which lists the total number of errors and warnings encountered during the compilation of the macro. Any errors mean that the macro is invalid and will not run. Depending on the type of error the compile may have stopped leaving a partially generated file which may not even be valid to AEL. The errors must be corrected before proceeding.

Warning messages do not prevent the macro from being generated, but they do indicate a problem which could result in unexpected results. The warnings should be resolved, especially if the PAM is not working as expected.

Use Design/Parameters to give the model parameters default values.

This is just a reminder message. It is very important that the Design/Parameters dialog be checked for any new PAM as well as any time the number or type of macro parameters change. Since new parameters get a default value of zero it is important to set them to a more reasonable value so that the insertion of a default component (the user didn't modify any of the parameters before insertion) looks correct (no lengths of zero or the like).

Macro Execution Messages

Warning: repeat exceeded limit, operation aborted

Warning: step exceeded limit for polar, operation aborted.

Both the Repeat and Polar controls keep track of how many iterations they perform. If there are to many it is possible that there is something wrong. It could be an infinite loop or just a very large count due to some error in the control specification or parameter value. To prevent any problems the iteration count is checked against a maximum and if it exceeds it the above warnings are displayed.

The default iteration limit is 1,000. This value can be modified using the configuration file option CELL_COMPILER_MAX_COPY. For details, see Configuration File Options.

Warning: infinite step detected for polar, operation aborted

As the Polar control is initializing it checks the angel start, stop, and step values. If <i>start < stop</i> with a negative step value, or if <i>start > stop</i> with a positive step value the control would go into an infinite loop. If these conditions are identified, the above warning is printed.

ERROR: obsolete compiled model version, re-compile model

This message indicates that the PAM was compiled using a previous version of the Graphical Cell Compiler. Due to changes made in the new version the PAM must be re-compiled. The source design does not need to be changed, it just needs to be opened and the Macro/Compile dialog opened to perform a fresh compile.

ERROR: invalid compiled model

The code testing what version of the Graphical Cell Compiler was used to create this model encountered an invalid version number. About the only way this could happen is if the PAM was manually edited and the number changed. In normal usage this message should never occur. If it does, simply re-compile the model and the problem should be corrected.

Control: [name], Shape: [type],

ERROR: operation on large shape data exceeded database numeric range.

Look for parameter values with missing units which default to meters.

As previously discussed, this error is displayed when the calculation for a shape's data points becomes too large. This is typically caused by a missing units designation in a control definition, or an incorrect unit assignment to a macro parameter.

For more information, see Missing or Incorrect Unit Designators.

Control: [name], Shape: [type],

ERROR: initial and current shape data have different number of (x,y) points.
Look for a User-Defined control which added/deleted points.

This error is caused by a User-Defined control which added or removed a number of (x,y) data points from a shape and did a return of type "Shape" which put the data back in the original location. This difference in the array size of the initial shape and current shape structures can cause errors in subsequent controllers.

If the User-Defined control is simply modifying (x,y) points it can return them as type "Shape". But if it is adding or deleting points is must return the resulting shape as type "Replace List" or "Append List" even if it is still a single item.

For more information, see User-Defined Control.

User-defined shape data for [type]

line [AEL line number] in [AEL file name]
This set of errors are possible results from a series of tests performed on the return data from a User-Defined control. The returned data must be an array of (x,y) values, that is a two-dimensional array.

A well formed array of (x,y) points would look something like: 

[[1, 2], [3, 4], [5, 6]]

The first test is to make sure the return data is an array. If it isn't the "not an array" message is displayed.
Next the data is checked to make sure it is a multi-dimensional array. If it isn't then the "is a 1-dimensional array" message is displayed. A one-dimensional array would look like: 

[1, 2, 3, 4, 5]

It is then checked to make sure it doesn't have more than two dimensions. If it does the "is a >2-dimensional array" message is displayed. A three-dimensional array would look something like: 

[[[1, 2], [3, 4]], [[5, 6], [7, 8]]]

The final check is to make sure the second dimension consists of only two elements, that is an (x,y) pair. If it doesn't then the "is not an (x,y) array" message is displayed. A two-dimensional array with two many elements in the second dimension would look something like: 

[[1, 2, 3], [4, 5, 6], [7, 8, 9]]

An additional test is performed if the User-Defined control is returning a list of primitives to make sure the return value is in fact a list. If it isn't then the "is not a list" message is displayed. If the list is OK, then each element of the list is run through the above tests.

Control: [name], Shape: [type], Parameter: [name]

As each control starts to execute all the parameters are gathered from AEL. A number of tests are performed to make sure the parameters are of the correct size and type. If any errors are found one of the above messages is printed to help isolate the problem.

In general these messages should never occur. The most likely cause of such an error is through manually editing the PAM and making changes to the Control's parameter list. If such an error were to occur, re-compiling the PAM should resolve it.

Preferred pin with the same number exists

When a PAM has a fixed number of pins, the component pins are assigned the same numbers as assigned to the ports in the source Layout. Since each port must have a unique number the pin numbers will also be unique.

The rules change if a source port is involved in a repeat control. Since all the copied pins must have a unique number, rather than using the port number they are allowed to take on the default numbering (next lowest available integer) as they are inserted. Normally this behavior works fine. A problem develops when an un-copied pin is created after a copied pin.

For example, assume the source design has two ports numbered: 1 and 2. Port 1 is part of a repeat control with a count of 4. So the component is generated with pins 1 through 4. It then generates a pin for port 2, and since it isn't part of a repeat is assigned the port number of 2 which is already in use by the second copy of port 1.

The above error is printed when this new pin (with the default number of 5) is re-assigned a number of 2. There are ways to control the pin creation order to work around the problem of mixing copied and non-copied pins in the same component.

For details, see Controlling Pin Numbers.

 

Privacy Statement  | Terms of Use  | Legal | Contact Us  | © Agilent 2000-2008 

Contents
Additional Resources