It is not yet Halloween but its coming. This week I resurrected an old trick for a client and thought I would share it here as a technical/tutorial contribution instead of my usual rhetoric.
A great deal of engineering is capturing a process so that it can be modified and repeated to achieve a desired result. In electronics development, that generally means a series of invocations of various EDA programs of different sorts and from different vendors. Each of these invocations work on what is referred to as “source code” and create some intermediate representation of that code which is then fed into the next EDA invocation in the process and so on.
Along with the source code is generally a tool specific EDA setup file that specifies how the process should be completed. Typical source code might be Verilog, VHDL, C++, System C, System Verilog, etc. The method for capturing the process might be in a scripting language such as tcsh, bash, perl, python, tcl, etc. All of these languages have multiple methods for procedurally configuring the source code or the scripted process to achieve variations on the result from the same source code.
However, in many cases, the setup files for the actual EDA tools do not support variations in their invocation within the same setup file.
In fact, different setup files is often the expected method for achieving variation. So, the scripting language is often called up to choose from a selection of setup files based on the variation that only the script has the ability to understand. By selecting a setup file consistent with the desired configuration, a modification of how the EDA tool interprets the source code is achieved and its contribution to the variation in results is realized.
This often leads to a number of similar and somewhat redundant setup files that need to be maintained. Generally, the difference between two setup files is less than 50% of the content of the file. It could even be just one or two out of hundreds or thousands of lines of setup information.
This leads to a process maintenance nightmare where one desired change in setup that is common to all of the various setup files requires that they all be modified and verified to validate the process.
The trick to simplify the redundant maintenance of setup files is also simple, use one of the methods built into the source code files listed above. This method is the “text preprocessor.”
Specifically, I use the ‘C’ code preprocessor invoked by the command:
cpp -E -P -D<variationMacro1> -D<variationMacro2> … <setupFile> -o <temporarySetupFile>
This allows the use of all of the ‘C’ preprocessor constructs to be used in the setup file. The scripting language can invoke the ‘C’ preprocessor as shown above and then pass the temporarySetupFile to the EDA tool.
The only issue is when ‘C’ preprocessor constructs conflict with the syntax of the tool setup file. There are several ways to get around this but I find that using the ‘sed’ editor before and/or after “cpp” allows for management of ‘cpp’ sensitive characters like ‘#’, ‘/*’, and ‘//’.
For example replacing ‘#’ with ‘##’ in the setup file before ‘cpp’ and then reversing the replacement after preserves the ‘#’ character that might be needed in the setup file. Replacing ‘//’ with ‘%’ or some other special character keeps ‘cpp’ from interpreting what follows ‘//’ in the setup file as a comment. These edits will not work if the original file has ‘##’ or ‘%’ characters that should be preserved but I have found that by understanding the syntax of the setup file and the syntax of ‘cpp’ it is generally not difficult to work around any conflicts by using some innocuous character substitution. And if ‘cpp’ does not meet your needs have a look at ‘m4’. I have never had to go there but if you do and you can then maybe you can write the next tutorial.
This trick can be used in more processes than just EDA development. It can be used in any textual based setup, source code, template, etc. to create customized variations based on ‘cpp’ constructs.
So, there is the treat.