Never miss a story from RF Engineering. Subscribe for in-depth analysis and articles.
The Team RF "μWaveRiders" blog series is a showcase for Cadence AWR RF products. Monthly topics will vary between Cadence AWR Design Environment release highlights, feature videos and spotlights, and software tips, tricks, and customization. Subscribe to receive email notifications about our latest μWaveRiders blog posts.
In the series μWaveRiders: Scripting in the Cadence AWR Design Environment blog, the use of scripting for automating repetitious commands as well as for post processing of simulated data was highlighted. The two main scripting languages in use are a language based on Visual Basic for Applications (VBA) and Python. One key enhancement mentioned in the blog related to the use of Python as a scripting language for AWR Design Environment software is the introduction of the pyawr library. This library wraps a number of lower level functions into a higher level interface between Python and the AWR software. Code completion is another key contribution of the pyawr library.
Using the pyawr library alone still requires that you reference API commands and API documentation written for VBA. A new Python library has been introduced that works in conjunction with the pyawr library to provide an even higher level API that provides commands that are oriented more towards Python syntax.
The AWR Design Environment API is an exhaustive set of commands for nearly every function that can be manually performed through the user interface. The API has a legacy formed around VBA, however, so Python programmers must convert the VBA-oriented syntax into Python-compatible commands. All of the code examples in the API documentation use VBA, which forces Python programmers to learn enough about the VBA structure and syntax to interpret the commands.
Many of the API commands do not follow Python coding conventions. In other words, the API is not “pythonic.” Among the non-pythonic issues of the API commands is array indexing that begins with one, not zero. This indexing is also not consistent in that some commands can use zero-based indexing, while others require one-based indexing. Another example of non-pythonic programming style stems from the lack of lists and dictionaries for data structures.
API commands used in the Python environment lack robust error trapping mechanisms and error messages tailored towards Python. Debugging to root cause can be a difficult and time-consuming process.
Arguably the biggest issue with using the API is the time spent looking up each command in the documentation. This is in addition to the time it takes to interpret the VBA-based command structure into a Python-compatible format. The API is organized around a VBA perspective that uses collection of objects. To use the listing of commands in the API documentation, you must be familiar with how VBA fundamentally uses collection of objects. This structure is not intuitive for the Python programmer.
A new Python library has been written to facilitate an interface between Python and AWR software using a command structure that adheres more closely to Python coding conventions. This library is labeled pyawr-utils and it is installed using the standard Python pip command. Comprehensive documentation for installing and using pyawr-utils is available.
Many of the challenges with the existing API are addressed when using the pyawr-utils, which offer:
Additionally, the pyawr-utils documentation includes code examples written in Python. Not only does this remove the time-consuming and error-prone process of interpreting the VBA-based documentation into Python, but it allows for direct copy and paste of the Python code into the Python development environment.
There is a growing body of complete code examples using the pyawr-utils library.
The initial version of pyawr-utils includes commands for circuit schematics, system diagrams, elements, equations, graphing, and data files. Future enhancements will include commands for layout, EM structures, optimization, yield analysis, and more.
By: Brian Avenell (Sr. Principal Product Engineer) and David Webster (Lead Product Engineer)Cadence AWR R&D - U.S.
For questions, general feedback, or suggestions for future blog topics, write to firstname.lastname@example.org.