Empresa De Acueducto Y Alcantarillado De Bogotá – Eaab

This section will include more detailed explanations and remarks on the scripts that have been used in the block generation script and other auxiliary scripts. Only the user-written scripts will be explained and included on the annexes while giving general explanations on company and Synopsys scripts.

3.4.1. Block Generation Script: run_gen.tcl

As explained on the previous section, this script is in charge of copying the desired scripts and running the set-up flow script to start and run the block.

As specified before, the initial code block of the script will copy and rename the needed scripts in the block folder.

After copying the desired scripts, sets up the main setup script of the flow, choosing different memory assignation depending on the block type.

One of the main points to take into consideration from the setup script calling:

 Typical setups will call an interface and a Graphical User Interface (GUI) while this script does not. This adds flexibility and reduces user managed steps, however it removes tolerance to errors as a block error will shut down the current job and give no error warning unless specified.

 User modifications are needed to change the memory requirements, log reports, type of machine used amongst others.

3.4.2. Reporter and parser: report_parser.tcl

This is the script in charge of generating reports and parsing them in a more compact format. The output files of this script are given in a Comma Separated Values format (.csv) to use them in other programs in order to analyse results.

The script has been designed to generate individual reports on different areas of interest such as:

 Total power information.  Clock power information.  Insertion delay.

 Routing information.  Local skew reports.  Wirelength information  Layer congestion.  Utilization.

 Clock area information.

By running the report manually it is also possible to execute this script on any step by selecting it in a script option.

Asides from the reports generation there are options to generate a more compact file with the final selected QoR file format. To avoid problems regarding scenario name due it being able to vary, the information is passed to the script manually.

The basic structure that is followed at each individual report and parsing of it is the following one:

 Check existence of scenarios.

 Generates the report or uses an existing report if present in the flow.

 Line by line analysis using the regular expression structure provided in the TCL package.

 Assignation to user made variables of the relevant information obtained via parsing.

This procedure is repeated for all individual report types, parsing and storing the information into user defined variables.

Once all the variables are obtained, individual CSV files are generated with all the information. Asides from the individual reports, a final file is generated containing the most relevant information. The information preparation and storage in a file is done as it follows:

 First, it is checked if the file must be generated and pre-preparation of obtained information is done.

 Once the data preparation is done, the file is created and opened. Then the information is written and the file is closed to avoid errors. It is necessary to define the separator used, to then make it available data sheet programs.

Most scripts with certain complexity in TCL require argument declaration to work correctly. The argument declaration is done outside of the main script and it must be parsed at the beginning of the script to extract the information.

At the argument declaration it must be declared how it is called, a description, and which type of variable it requires and whether it is optional or not.

3.4.3. Clock Structure Analyser: clock_structure_analyser.tcl

This script is in charge of analysing the physical clock structure file of a given block and extract relevant information. The main information being obtained is:

 Number of repeaters, Integrated Clock Gating Cells (ICG), clock sinks, balance pins and clock sources.

 Fanout of repeaters and ICGs.  Types of repeaters and ICGs used.  Location of clock cells and sink pins.  Wire and cell capacitance.

Asides from this information, this script provides basic math support to extract average

fanout, average Manhattan distance between clock cells and sinks, average cell and wire

capacitance, etc.

Debugging code has been added to check if the assumptions made in terms of possible line structures in the report exist.

Overall, the data parsing and handling has been done similarly to the report_parser.tcl script with some modifications to data treatment, focusing more on the use of arrays when possible as they prove to be better optimised and given the sheer size of the clock reports analysed can cut some machine time needed.

As done previously, the first step is checking if a clock structure report file exists, if it does not, or it is wanted anyways, a new file will be created on a user selected directory while keeping old files.

When the file is extracted, several counters and auxiliary variables will be declared to be used later. The counters will be used to obtain numbers on how many repeaters, ICGs, sink pins and balance pins are obtained. The sink pins are the flip-flops of the design while the balance pins are used to balance capacitance in the clock branches.

Five different structures have been found to be present in any clock structure file generated by the tool reporter and thus taken into consideration. There is one line type for clock sources, repeaters, ICGs, sink pins and balance pins.

For each type, it is checked if the current line follows its structure and then the information is extracted following the same pattern used in the other scripts that need parsing.

The obtention of the average and maximum repater and ICG is done iterating over the obtained arrays in the regular expression. For each position on the array, the fanout obtained is read and several counters are increased depending on the value of the fanout.

The Manhattan distance is defined as the distance measured along the defined axis. On this case, Cartesian axis are used and the total Manhattan distance will be defined as:

(12) On this case, the Manhattan distance has been calculated between and endpoint driver and the downstream sinks and balance pins.

The capacitance information is also obtained via the attribute of the nets connected to an endpoint driver.

3.4.4. Clock pin modification script: replace_clockpin.tcl

In some experiment sets, the input clockpin is centered and a superior layer is used to check if better results can be obtained in terms of clock building. The pin movement was done after the initial cell placement. To move the clock pin it is needed to give the initial clock name to locate and remove it, and then create a new clockpin on the new position. To perform the pin movement several information is needed:

 Current clockpin name.  Block dimensions.  Pin shape type  Pin margin.

The block dimensions are used to calculate the middle point of the block, while the pin margin is used to avoid conflict with other block tracks, memories, etc. The shape type is defined in by the tool and is needed to create the shape.

To move the clockpin, the existing shape must be deleted and a new clockshape is created.

3.4.5. Report combiner: block_combiner.tcl

Given how the block generator and report generation is done, one report is generated for each block. Because of that reason, it is needed an auxiliary report to combine existing report CSV files.

This script combines the existing reports given separated by block type and block name and has the capability of performing some mathematical operations to simplify the analysis. Similar to other blocks, the CSV file generation is done following a similar procedure as in other cases.

The block selection is done with an empty list that adds all the blocks on which data has been defined. Similarly to other cases, the existing data has been parsed in order to simplify the results.

For each list, the data is obtained using a regular expression as in previous cases. For each block, the report parsed file is analysed which simplifies obtaining the data.

A math flag has been enabled to perform some percentages to ease further analysis. Once the data is obtained, if the math flag is active, it will perform some percentages to ease further analysis, the first block passed is used as a reference and the information obtained is passed to a new set of variables.