Automatic Inter-procedural Parallelization
toc
/iii HOMECONTENTS INDEX ContentsWhat’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvi 1.Introduction to Automated Chip SynthesisProduct Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3Data Management Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Known Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-92.Running Automated Chip SynthesisInvoking the Synthesis T ool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2Preparing Y our Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3Inputting the RTL Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4Running acs_read_hdl in Update Mode. . . . . . . . . . . . . . . .2-5Running acs_read_hdl in Standard Mode . . . . . . . . . . . . . .2-7Specifying the HDL Source Files . . . . . . . . . . . . . . . . . . . . .2-8/ivHOME CONTENTSINDEX About the File Input Process . . . . . . . . . . . . . . . . . . . . . . . .2-10Applying the T op-Level Constraints . . . . . . . . . . . . . . . . . . . . . .2-11Validating Y our Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11Generating Verification Setup Files . . . . . . . . . . . . . . . . . . . . . .2-13Compiling Y our Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15Reading the GTECH Database . . . . . . . . . . . . . . . . . . . . . . . . .2-17Resolving Multiple Instances. . . . . . . . . . . . . . . . . . . . . . . . . . .2-17Identifying Compile Partitions . . . . . . . . . . . . . . . . . . . . . . . . . .2-18Generating Partition Constraints for GTECH Designs. . . . . . . .2-19Generating Logical Partition Constraints . . . . . . . . . . . . . . .2-19Generating the Compile Scripts. . . . . . . . . . . . . . . . . . . . . . . . .2-24Script Termination Errors . . . . . . . . . . . . . . . . . . . . . . . . . . .2-28Generating the Makefile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-29Running the Compile Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31Analyzing a Successful Run . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31Analyzing an Unsuccessful Run . . . . . . . . . . . . . . . . . . . . . . . .2-32Using the HTML Report Files . . . . . . . . . . . . . . . . . . . . . . . . . .2-32Refining Y our Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-35Reading the Gate-Level Design. . . . . . . . . . . . . . . . . . . . . . . . .2-37Generating Partition Constraints for Gate-Level Designs . . . . .2-37Generating the Compile Scripts. . . . . . . . . . . . . . . . . . . . . . . . .2-40Generating the Makefile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-43Running the Compile Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-43/vHOME CONTENTSINDEX 3.Customizing Automated Chip SynthesisCustomizing the Directory Structure . . . . . . . . . . . . . . . . . . . . . . . .3-2Specifying Locations for Pass-Dependent Files. . . . . . . . . . . . .3-5Placing Multiple Files in the Same Location . . . . . . . . . . . . . . .3-6Accessing Files in a Customized Directory Structure . . . . . . . .3-7Creating the Directory Structure. . . . . . . . . . . . . . . . . . . . . .3-7Reporting the Directory Structure . . . . . . . . . . . . . . . . . . . .3-8Reporting Path Specifications . . . . . . . . . . . . . . . . . . . . . . .3-8Locating Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Controlling Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . .3-9Customizing T asks in the Default Flow . . . . . . . . . . . . . . . . . . . . . .3-12Generating the Makefile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Resolving Multiple Instances. . . . . . . . . . . . . . . . . . . . . . . . . . .3-13Selecting a Master Instance. . . . . . . . . . . . . . . . . . . . . . . . .3-15Uniquifying the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15Ungrouping a Subdesign . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15Partitioning the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16Partitioning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16Specifying Compile Partitions. . . . . . . . . . . . . . . . . . . . . . . .3-18About Autopartitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20Changing Compile Partitions . . . . . . . . . . . . . . . . . . . . . . . .3-21Generating Partition Constraints . . . . . . . . . . . . . . . . . . . . . . . .3-22Writing a Custom Budgeting Script . . . . . . . . . . . . . . . . . . .3-22Using an Override Constraint File . . . . . . . . . . . . . . . . . . . .3-23Generating the Compile Scripts. . . . . . . . . . . . . . . . . . . . . . . . .3-24Setting Compile Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .3-25Writing a Custom Compile Strategy. . . . . . . . . . . . . . . . . . .3-34/viHOME CONTENTSINDEX Writing a Custom Report Script . . . . . . . . . . . . . . . . . . . . . .3-37Writing a Custom Compile Script. . . . . . . . . . . . . . . . . . . . .3-38Running the Compile Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-41Specifying the Make Utility. . . . . . . . . . . . . . . . . . . . . . . . . .3-41Specifying the Number of Parallel Compile Jobs . . . . . . . . .3-42Checking Out Required Licenses. . . . . . . . . . . . . . . . . . . . .3-43Running the Compile Job in Batch Mode. . . . . . . . . . . . . . .3-44Using GRD to Submit Compile Jobs . . . . . . . . . . . . . . . . . .3-47Running the Compile Job From the UNIX Prompt . . . . . . . .3-48Modifying the Automated Chip Synthesis Flow. . . . . . . . . . . . . . . .3-50Adding Chip-Level Compile Runs . . . . . . . . . . . . . . . . . . . . . . .3-51Refining Y our Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-51Recompiling Y our Design. . . . . . . . . . . . . . . . . . . . . . . . . . .3-52Updating Y our Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-58Modifying the HDL Source Code . . . . . . . . . . . . . . . . . . . . .3-59Updating the Unmapped Design . . . . . . . . . . . . . . . . . . . . .3-59Merging the Modified Subdesigns . . . . . . . . . . . . . . . . . . . .3-61Recompiling the Changes . . . . . . . . . . . . . . . . . . . . . . . . . .3-64Simplified Update Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-66Update Flow That Saves All Design Changes . . . . . . . . . . .3-68Changing the Chip-Level Compile Commands . . . . . . . . . . . . .3-70About the Chip-Level Compile Commands . . . . . . . . . . . . .3-71Customizing a Chip-Level Compile Command. . . . . . . . . . .3-75Cleaning Up the Data Directories . . . . . . . . . . . . . . . . . . . . . . . . . .3-76Removing Selected Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-77Removing a Data Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-77/viiHOME CONTENTSINDEX 4.Automated Chip Synthesis T utorialPreparing to Run the T utorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Meeting the Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Creating the T utorial Directories . . . . . . . . . . . . . . . . . . . . . . . .4-2Browsing the Setup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Running the T utorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5Preparing the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8Analyzing the Compiled Design. . . . . . . . . . . . . . . . . . . . . . . . .4-11Refining the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12Analyzing the Refined Design . . . . . . . . . . . . . . . . . . . . . . . . . .4-13Index。
Slides2
Creating Concurrent Processes
• FORK-JOIN construct:
Ptheads: Creation and termination
pointer to ID
pthread_create ( pthread_t *thread_handle, const pthread_attr_t *attribute, void * (*thread_function) (void * ), void *arg) pthread_join ( pthread_t thread void **ptr)
Latency Hiding
While one thread is waiting for a communication operation, others can utilize the CPU.
Scheduling and Load Balancing
Allow the programmer to specify a large number of concurrent tasks and support dynamic mapping of tasks to processors with minimal idling overheads.
forall Construct:
forall (i = 0; i < n; i++) { S1; S2; . . Sm; }
Example:
forall (i = 0; i < 5; i++) { a[i] = 0;
Cruces for Parallel Programming with Shared Memory multiprocessor system How do processes share information? How do processes synchronize? In shared-memory model, both accomplished through shared variables Creating Concurrent Processes Dealing with the Sharing Data Synchronization Problems
RelNotes-RH-8.1.2
RedHawk TM Release NotesRelease 8.1.2July 16, 2008IntroductionSoftware version 8.1.2 continues efforts to improve the general functionality, speed and usability of RedHawk.A. General Enhancements•Enhanced power calculation to support instance-based Block_Power_For_Scaling GSR specifications for hierarchical MMX applications.•Enhanced support for both PWL and fixed time step formats in current modeling for macro model generation. Previously, only fixed-step waveforms were provided.•Enhanced the ‘dump mmx_pin_info’ command output current data, when ‘-o’ or ‘-avg_volt_tw’ options are not specified. The data is now displayed in the GUI and in the log file. No output file specification is now required, but no separate report is created with detailed transistor pin current in this case.•Enhanced the power EM display to sort and display the potentially very large “List of Worst EM”report, allowing display of only selected nets using the new “Report Setting” button in the dialog.•Enhanced the power EM display to allow viewing EM data for any combination of metal and via layers, as well as metal length, width or EM threshold settings.•Enhanced the power EM display to dump out a text report of the existing “List of Worst EM” table using the new “Export List” button.•Enhanced the "List of Worst EM" report by adding a column of “Current Direction” data to the table in signal EM mode.•Enhanced sim2iprof to add support for separate FSDB files for different states (Read, Write, Standby, ...) for memories.•Enhanced sim2iprof to support individual scaling for current waveforms and leakage for each individual state, supporting multiple configuration files on one command line. Each configuration file now can define a simulation result for each designated state, and specify scaling for current waveforms and leakage for each state separately.•Enhanced ACE to support user-specified leakage values in the following format:leakage_i {<vdd_pin> <gnd_pin> <leakage_A>...}Example:leakage_i {vdd1 gnd 75uA}•Enhanced ACE to support pwlcap data for low power analysis using the '-pwc' option in the command line. When using the '-pwc' option, users must specify leakage values in theACE configuration file using keyword 'leakage_i' (see previous item).PRIMARY_POWER_NET <pinname>PRIMARY_GROUND_NET <pinname>If users specify the primary pin names, ACE uses the user-specified arc to perform post-processing and generates pwcap data. If users do not specify ‘-pwc’, ACE by default uses the first P/G pins listed as the primary P/G pins.•Enhanced ACE to allow specification of voltage sweep values for PWCAP data generation using the keywordSWEEPVALUE <v1> <v2> ...If users do not specify voltage sweep values, ACE by default uses 11 standard VDD values to do scaling (10%, 20%, ..., 100%, and 110% of VDD).•Enhanced PWCAP characterization to support the APL keyword SPICE2LEF_PIN_MAPPING, which previously did not work. SPICE2LEF_PIN_MAPPING now supports switching currents, CDEV, and PWCAP data.•Enhanced early analysis methodology by adding automatic pad instance connection, which creates plocs using the new GSR keyword AUTO_PAD_CONNECTION_LAYERS. For example, if the user uses the syntaxAUTO_PAD_CONNECTION_LAYERS {METAL5METAL6}RedHawk searches within the neighborhood of each pad cell and generates one P/G source for each pad cell at the closest location on METAL5 and/or METAL6, whether or not it has METAL5 or METAL6 pins defined in LEF.•Enhanced unplaced instance handling using the GSR keywordIGNORE_UNPLACED_INSTANCE. If IGNORE_UNPLACED_INSTANCE is set, all instances with status ‘UNPLACED’ in DEF are ignored.•Enhanced handling in LEF 5.6 parser to accept new LEF 5.7 data syntax (without processing it). •Enhanced automatic pad location creation inside GDS2DEF generated DEF files using the GDS2DEF configuration file keyword GENERATE_PLOC. There are two options:GENERATE_PLOC [USE_TEXT_LABEL | USE_INPUT_LEF_PIN ]. The existingUSE_TEXT_LABEL option uses text labels to create pad locations, while the newUSE_INPUT_LEF_PIN option uses the input parent LEF P/G pins to create pad locations. The GSR keyword ADD_PLOC_FROM_TOP_DEF must be set to 1.•Enhanced substrate extraction using the new GDS2DEF keyword‘EXTRACT_SUBSTRATE_REGIONS <filename>’, which allows users to use a file to specify the bounding boxes of regions within which substrate geometries are to be extracted.•Enhanced aplreader to add a '-pp' option to obtain only the positive peak current values. No impact on existing flow or results.•Enhanced simulation to prevent unnecessary scan loop runs, which should not change results. •Enhanced the DvD movie function to allow DvD creation on demand, even when the GSR DYNAMIC_MOVIE keyword has been set to 0 (off). A DvD movie can be created after simulation by using the menu command Results -> Movie -> Make or the TCL command ‘movie make ’. If no DvD movie is needed, users should set DYNAMIC_MOVIE to 0 in order to save disk space otherwise used to create a DvD movie during simulation (set to 1 by default). There is a check for sufficient DvD movie disk space prior to starting RedHawk.•Enhanced support for PowerStream using the new GSR keywordPOWER_MCF_MULTI_CLOCK [ 0 | 1], which automatically controls the generation of vectors for multiple clock cells as defined in the MCF file.•Enhanced PowerStream functionality to support multi-state vectorless analysis.•Enhanced vectorless scan flow to use power values in the file specified by the GSR keyword INSTANCE_POWER_FILE <filename>.• Enhanced the Redhawk/Liberty parser to support the GSR keywordLIB_IGNORE_IO_VOLTAGE [0|1], for which, when set to 1, RedHawk ignores all I/O voltages. •Enhanced power-down flow to provide actual internal cell power-down current waveforms. •Enhanced handling of GDS2DEF-inserted sink pins in the adsRpt/<design>_<net>.PinInst.unconnect file, using a new GSR keyword (default off) to remove them from the list:IGNORE_GDS2DEF_UNCONNECTS [0 | 1]When set to 1 GDS2DEF-inserted pin instances are removed from theadsRpt/<design>_<net>.PinInst.unconnect file. So both conditions of missing pin instances in GDS2DEF memories due to floating metal wires are now covered:1. Flagging with GDS2DEF validation.2. Ignoring with GSR keyword IGNORE_GDS2DEF_UNCONNECTS•Enhanced Liberty library processing to ignore ‘compact_ccs’ entries. Previously RedHawk flagged these entries as errors.•Enhanced the ‘gds2def –m’ command to support wild cards in the NET section of the configuration file, which previously were not correctly handled.•Enhanced GDS2DEF to support new GDS2DEF keyword GRAY_BOX_CELLS 0, depending on the setting of OUTPUT_CELLS_TO_LEF [ 0/1 ].•Enhanced GDS2DEF naming of metal cap vias in the layermap. Available layer map definitions for the metal cap include existing “c”, as well as new names “mcap” and “mim”, to define the layer type. In addition, another field is added to specify a name to be used for via layer between the metal layer and corresponding mim cap layer. The syntax now is:<mim_cap_layer_name> [ c| mcap| mim] <gds_layer_num><gds_text_layer_num> [mim_cap_via_layer_name] There is no change in default behavior.•Enhanced GDS2DEF to allow switch pin names the same as net names instead of pin names specified by user. The EXTRACT_SWITCH_CELLS and DEFINE_SWITCH_CELLS keywords now accept “HEADER” and “FOOTER” switch types either in lower or upper case letters. •Enhanced GDS2DEF processing to allow input LEF P/G pin geometries in the generated LEF/DEF, using the keyword IGNORE_LEF_PG_PIN_GEOMETRY [ 0 | 1 - default] for gdsmem.By default gdsmem (gds2def -m) does not bring any of the input LEF P/G pin geometries in the generated LEF/DEF. Setting 'IGNORE_LEF_PG_PIN_GEOMETRY 0' may be used to allow these pin geometries in the output LEF/DEF.•Enhanced CPM modeling by exporting the NSPICE netlist to the file get_cdie.sp, which can be used to calculate Rdie/Cdie at the specified frequency (50 MHz by default, unless the user edits the get_cdie.sp file), and to plot Cdie(f) and Rdie(f) for frequencies ranging from 1 MHz to 1 GHz.This new file has the following benefits:Eliminates user errors, which are likely for a CPM model with a large number of ports.Saves user time that would be required to create the netlist by hand.•Enhanced PsiWinder to remove the requirement for a complete RedHawk .apache/ directory.Now the ‘setup psiwinder’ command must be run to prepare the files required prior to running PsiWinder.•Enhanced PsiWinder to now support multiple-Vdd/Vss designs in PsiWinder ‘basic’ mode.B. Issues Resolved•Resolved an issue with transistor pin mapping in the save and reload flow, when multiple pins for intentional decaps map to the same transistor device name. Now when exporting a DB,complete pin data is added to the DB for the next import. Users must rerun analysis toregenerate the DB; thereafter save and reload has correct pin mapping.•Resolved an issue during GUI measurement using both left and right mouse buttons for Zoom and Ruler functions, in which case the starting point of the measurement moved. Now Zoom is disabled when dragging the left button in Ruler mode. Zooming can still be performed whileusing the Shift/left button activation of the Ruler.•Resolved an issue in the sim2iprof configuration file to improve support of syntax of the following type:CELL CELL_NAME {FILENAME {CELL_NAME.fsdb POWER_NAME=v1CELL_NAME.fsdb1 POWER_NAME=v2CELL_NAME.fsdb2 POWER_NAME=v3CELL_NAME.fsdb3 POWER_NAME=v4}}•Resolved an issue in which GENERATE_PLOC created shorts caused by improper layermap specifications.•Resolved an issue in which GENERATE_PLOC did not work when syntax of the type "VDD @31 12 34" was used.•Resolved an issue in extraction of ndiff and pdiff geometries in GDSMMX.•Resolved a tracing issue with the INTERNAL_DBUNIT keyword, which failed when keywords were in the wrong order in the configuration file. The keywords now can be in any order.•Resolved an issue in internal DB unit handling using the GDS2DEF configuration file keyword INTERNAL_DBUNIT; GDS2DEF now automatically handles 5nm internal DB units. Previously when the GDSII data internal DB unit was more than 1 nm, GDS2DEF did not handle the case correctly.•Resolved an issue with the GDS2DEF keyword MMX_OUTPUT_CELLS, which did not properly ignore geometries inside specified cells.•Resolved several Boolean layer handling issues with the '&' and '-' operators and layer definition reporting. Also, the log messages for Boolean layer handling have been improved.•Resolved an issue with an input LEF file specification, in which the generated LEF file had names from the text labels specified in the net section of the configuration file.•Resolved an issue with long run times in GDS2DEF configuration file parsing. When the number of nets defined in the NET section of the configuration file is very large (for example, more than one billion, as can be the case with signal EM), the run time for configuration file parsing wasvery long (2-3 hours). Now the processing time is 2 to 3 minutes.•Resolved an issue when OUTPUT_DIRECTORY is specified in the GDS2DEF configuration file and also ‘-out_dir’ specified in the gds2def command line. Previously in this case the outputdirectory was deleted.•Resolved an issue causing small variations in result values in theadsRpt/Dynamic/<design>.ipwr.out and the adsRpt/Dynamic/freqd_ipwr.out files.•Resolved power calculation issues which previously caused incorrect charge in multi-state vectorless analysis, and incorrect multi-rail instance ground charge and incorrect power charge scaling in APL power mode.•Resolved an issue in GSC state handling in which PowerStream previously did not honor all states consistently.•Resolved an issue in PowerStream in which switching scenarios were not always generated correctly.•Resolved an issue in which power reports for certain clock nets had some incorrect values.•Resolved issues in VCD/FSDB parsing to insure that all signal names are read in correctly.•Resolved issues in multiple-voltage AVM analysis that had large differences in peak current values between multiple-voltage and single-voltage AVM cases with the same parameters.•Resolved an issue in which APLSW was not handling the “{“ character properly. No impact on existing flow and results.•Resolved an issue in which ACE failed on some device model parameters.•Resolved an issue in the Spice parser to now identify and flag invalid Spice sources. RedHawk only supports constant and PWL EFGH current and voltage elements. If other types of sources are specified in Spice, RedHawk writes an error message and stops.•Resolved an issue in power calculation for early stage analysis in which block power defined in the GSR keyword BLOCK_POWER_ASSIGNMENT used the total power for each block. Forblocks with multiple power supplies, this caused inaccuracies in dynamic power analysis. Nowpower is computed for each power domain separately, providing more accurate results.•Resolved an issue in VCD analysis of incomplete calculation of effective Vdd values for memories or large instances with many power pin nodes, which sometimes caused the reported highest metal DvD values to be much higher than the worst case instance DvD values. Thisoccurred because the voltage drop of a few nodes on each instance was investigated to mitigate run time concerns. Now every node is evaluated to find the worst-case Vdd drop or Vss rise for each instance to improve the accuracy of results. The user must rerun the session with the new release to insure that all DvD results are correct. Internal testing indicates little impact on mostresults from this issue and only a small run time penalty.•Resolved an issue in MMX and RedHawk in which APLMMX failed in device location mapping when users specified FLAT_MHIER_MAP "/M" ".", and the MOS device hierarchy did not start with “/MM”, “/MP”, or “/MN”. The MOS device hierarchy requirement is now relaxed if the device flattened name starts with “M”. Users must rerun APLMMX using the new release.•Resolved an issue when Ultrasim was specified as Spice simulator for APLMMX (since Ultrasim cannot run AC analysis required for decap analysis). If user has a Spectre format netlist, specify ACE_SPECTRE <netlist path> in the ACE configuration file, or inside APLMMX, use the aplmmx configuration file keyword{ACE_OPTIONACE_SPECTRE <netlist_path>}NSpice is used as the default simulator for regular netlist formats.•Resolved an issue when the time resolution was inconsistent between APLMMX and the simulation output file, causing improper expansion or compression of waveforms.•Resolved an ixf file mapping issue when device names are not specified below instance level.Device level name mapping is now obtained from the netlist.•Resolved a PsiWinder issue with timing analysis involving non-switching instances. PsiWinder now assigns a reasonable switching time to provide the needed accuracy in the calculation.•Resolved an issue when SPEF has missing nets, which caused PsiWinder to error out.PsiWinder now obtains missing connectivity from the DEF files.C. Bugs Fixed•Fixed a crash caused by P/G-aware memories with missing pin connections.•Fixed a crash scenario in glitch report handling when the VOLTAGE_LEVEL option (for width measurement) in the GSR keyword DVD_GLITCH_FILTER was set larger than the ideal voltage.Now in this case all instances are filtered out, but processing continues. Users must check the validity of the VOLTAGE_LEVEL setting to insure proper results.•Fixed a crash in the Spectre interface that occurred when the Spectre netlist had certain model definitions in it.•Fixed a crash in GDS2DEF/GDSMMX while handling and improperly tracing MIM caps.•Fixed a crash when some power pins in a multi-rail instance were not connected.•Fixed a crash when using the TOP_CELLS GDS2DEF configuration file keyword with certain logical layer operations.。
通信英语课后短语翻译
通信英语课后短语翻译1.PCM原理抽样量化与编码:sampling, quantizing and coding 话路:speech channel幅值: amplitude value抽样频率: sampling frequency抽样速率: sampling rate脉冲流: stream of pulses重复率: repetition rate编码过程: coding process模拟信号: analog signal传输质量: transmission quality数字通信: digital communication数字传输: digital transmission含噪声的环境: noisy environment传输路由: transmission path信噪比:signal-to-noise ratio信号电平:signal levels噪声功率: noise power地面系统: terrestrial system二进制传输: binary transmission反向操作: reverse operation8-位码序列: 8-digit sequence接受端: receiving terminal帧格式:frame format同步字:synchronization word2.异步串行数据传输串行接口serial interface显示终端CRT terminal发送器与接收器transmitter and receiver数据传输data transmission数据流data stream闲置状态the idle state传号电平mark level空号电位space level起始位start bit停止位stop bitT秒的持续时间duration of T seconds奇偶校检位parity bit错误标志error flag传输错误transmission error下降沿falling edge符号间的空格intersymbol space接收机的定时receiver timing本地时钟local clock磁带magnetic tape控制比特control bit逻辑1电平logical 1 level二进制数据binary data明显的缺点obvious disadvantage3.ISO联网标准联网技术networking technology国际标准化组织the international organization for standardization 参考模型reference model数据分组data pakects应用程序application program网络媒体network media分层layering硬件和软件hardware and software表示层the presentation layer传输层the transport layer数据链路层the data link layer网络服务network services文件接入file-access数据格式the data format主机host协议protocol连接connectivity逻辑选址logical addressing4.互联网网络资源：network resource信息服务：information services远程终端：remote terminals互联的系统：interconnected systems 命令：command电子邮件：electronic mail主机：host无线信道：wireless channels搜索工具：searching tools用户界面：user interface存取：access文本信息：textual messages协议：protocol超文本协议：hypertext protocol5.光纤通信介绍光纤通信:optical fiber communications 光源：light source波长：wavelength激光器：laser色散：dispersion传输介质：transmission medium多模光纤：multi-mode fiber长途干线：long-haul trunks单模光纤：singer-mode fiber带宽：bandwidth带宽用户：wideband subscriber纤维光学：fiber-optics商用技术：commercial technology门限电流：threshold current光检测器：photodetector波分复用：wavelength multiplexing纤维光网络：fiber-optic network视频带宽：video bandwidth6.同步数字系列同步数字系统：synchronous digital hierarchy 国际标准：international standard信号格式：signal format网络节点接口：network node interface支路信号：tributary signals数字交叉连接：digital cross-connection网络管理：network management网络维护：network maintenance网络运营者：network operators传输速率：transmission rate支路映射：tributary mapping灵活性：flexibility用户业务：subscriber services覆盖层：overlay levels制造商：manufacturer同步传输帧：synchronous transmission frame线路终端复用器：line terminal multiplexer分插复用器：add-drop multiplexer再生中继器：regenerator灵敏度：sensitivity虚容器：virtual container成帧字节：framing bytes段开销：section overhead端到端传输：end-to-end transmission误码监视：error monitoring信号处理节点：signal processing nodes净负荷：payload指针：pointer7.波分复用对光特性的理解：the understanding of the property of light 基本重要性：the fundamental important想象今天的通信系统：to imagine the communication system of today 光的高速公路：the highway of light巨量的信息：the massive amount of information采用通信新技术：to adopt new communication technology 大量的视频信息：the large amounts of video information波分复用：the wave divide multiplexing只发送单个波长：to send only one wavelength传输大量的波长：to transmit a large amount of wavelength 无差错传输：the error-free transmission自愈特性：the self-healing properties直接接入光网络：to access directly to the optical network视频信息：the video information8.蜂窝式移动电话系统蜂窝式移动电话：cellular mobile telephone服务性能：services performance频谱：frequency spectrum频带：frequency band微处理器：microprocessor移动手机：mobile unit广播业务：broadcast service天线：antenna子系统：subsystems移动用户：mobile subscriber服务能力：service capability利用率：utilization带宽：bandwidth单边带：single-sideband扩频：spread spectrum大规模集成电路：large scale integrated circuits 蜂窝点：cellular site蜂窝交换机：cellular switch无线机架：radio cabinet呼叫处理：call processing9.全球移动通信系统个人通信personal communication通信标准communication standards固定电话业务fixed telephone services网络容量network capability移动交换中心mobile switching center国际漫游international roaming宽带业务broadband services接口转换interface conversion频谱分配frequency allocation模拟方式analogue mode蜂窝通信原理cellular communication principle拥塞jamming蜂窝裂变cellular splitting基站base station寄存器register收费功能billing function接入方法access method突发脉冲传输方式bursty transmission mode开销信息overhead information切换算法handover algorithms短消息服务short message services技术规范technical specification10.3G移动电话the mobile telephone第三代移动业务the third generation mobile service 互联协议the Internet Protocol无线通信the wireless communication手机the handset全球漫游the global roaming无线标准the wireless standard蜂窝点the cell site峰值数据速率the peak data rate平均吞吐量the average throughput下载the download多址接入the multiple access扩频技术the spread spectrum technology时隙the timeslot11.电路交换和分组交换电路交换circuit switching分组交换packet switching报文交换message switching子网subnet信头header目的地址destination address误差控制error control存储转发方式store-and-forward manner突发性bursty传输时延transmission delay中间交换设备intermediate switching equipment 交换技术switching technique返回信号return signal报文处理机message processor给定最大长度given maximum length信息转移information transfer随机性random专用电路dedicated circuit电路利用率channel utilization12.A TM异步转移模式异步转移模式asynchronous逻辑信道logical channel虚电路virtual circuits虚路径virtual paths建议recommendation网络层network level业务与应用层service and application虚连接virtual connection信息高速公路information superhighway 点播电视video-on-demand统计复用statistical multiplexing数字化的信息digital information标识符identifier协议protocols网络节点network node宽带网broadband networkATM论坛ATM forum面向未来future-proofed图象编码image encoding虚拟专用网virtual private network数据处理data processing17.NGN信息技术the information technology数据包the data package电信行业the telecommuniccation industry 固定网业务tge fixed-network services网络运营商the network operaters接入技术the access technology核心网the coer network互联协议the internet protocol基于分组的网络the packet-based network 业务提供商the service provider管理层the management level网关the gateway传输平台the transport platform路由器the router交换机the switch增值业务the value-added services千兆字节the gigabyte无线连the wireless connection可编程器件the programmable devices媒体网关the media gateway。
软件编程规范(MISRA_C)
软件编程规范目录一环境二语言扩展三文档四字符集五标识符六类型七常量八声明与定义九初始化十数值类型转换十一指针类型转换十二表达式十三控制语句表达式十四控制流十五 switch语句十六函数十七指针和数组十八结构与联合十九预处理指令二十标准库二十一运行时错误一环境规则1.1（强制）：所有代码都必须遵照ISO 9899:1990 “Programming languages - C”，由ISO/IEC 9899/COR1:1995，ISO/IEC 9899/AMD1:1995，和ISO/IEC9899/COR2:1996 修订。
规则1.2（强制）：不能有对未定义行为或未指定行为的依赖性。
这项规则要求任何对未定义行为或未指定行为的依赖，除非在其他规则中做了特殊说明，都应该避免。
如果其他某项规则中声明了某个特殊行为，那么就只有这项特定规则在其需要时给出背离性。
规则1.3（强制）：多个编译器和/或语言只能在为语言/编译器/汇编器所适合的目标代码定义了通用接口标准时使用。
如果一个模块是以非C 语言实现的或是以不同的C 编译器编译的，那么必须要保证该模块能够正确地同其他模块集成。
C 语言行为的某些特征依赖于编译器，于是这些行为必须能够为使用的编译器所理解。
例如：栈的使用、参数的传递和数据值的存储方式（长度、排列、别名、覆盖，等等）。
规则1.4（强制）：编译器/链接器要确保31 个有效字符和大小写敏感能被外部标识符支持。
ISO 标准要求外部标识符的头6 个字符是截然不同的。
然而由于大多数编译器/链接器允许至少31 个有效字符（如同内部标识符），因此对这样严格而并不具有帮助性的限制的适应性被认为是不必要的。
必须检查编译器/链接器具有这种特性，如果编译器/链接器不能满足这种限制，就使用编译器本身的约束。
规则1.5（建议）：浮点应用应该适应于已定义的浮点标准浮点运算会带来许多问题，一些问题（而不是全部）可以通过适应已定义的标准来克服。
Software TM (STM) Hardware TM (HTM) Hybrid TM (HyTM)
Keine neue Speichertechnologie wie DDR2,DDR3…
Vortrag „Transactional Memory“ von Erdin Sinanović
4
Was ist Transactional Memory?
Keine neue Speichertechnologie wie DDR2,DDR3… Programmierkonzept für einfacheres paralleles Programmieren
Interprozessor-Bus muss hohe Bandbreite haben Falls Commit zu groß für den Cache, muss der Bus blockiert werden Algorithmus in Hardware-naher Sprache kann schneller sein
Vortrag „Transactional Memory“ von Erdin Sinanović
8
Wie funktioniert TM?
1. Code (Transaction) wird ausgeführt 2. Es entsteht ein Block von Writes (werden in Cache geschrieben) 3. Wenn Transaction fertig, systemweite Erlaubnis zum Commit einholen 4. Wenn Erlaubnis erteilt, werden alle Writes auf einmal in den Shared Memory geschrieben
计算机专业英语教程 第四版 部分翻译和简答题
翻译：1、C++’s advantages include strong typing, operator overloading, and less emphasis on the preprocessor.C++的优点包括强类型，运算符重载和较少地强调预处理器。
2、A program instruction or a piece of data is stored in a specific primary storage location called an address.程序指令和数据是存储在主存中一个特殊的位置，称为地址空间3、A high-level language is an artificial language with which we can write various instructions. This is possible not because computer processors are now so technologically advanced that they can ‘understand’ these langu ages. You should translate from programming languages into machine language which can be understood by the computer processors. Compilers can accomplish this task. This does mean that a high-level language program is not directly executable: it must be compiled to produce processor program, which is executable.高级语言是一门人工的我们可以写入各种各样指令的语言。
Pilot Flow Training - 10_Formality
Pilot Flow TrainingFormal Verification(Pilot 3.1)Predictable SuccessObjectives•In this module we will cover the following:-Formality•How Formal Verification runs in Pilot•Use of Formality global scripts and local constraints © 2006 Synopsys, Inc. (2)•Invoking Formality to debug failing verifications •How to include Formal tasks in the optimize StepsNote•MVRC is not covered in this module but it is covered within the UPF training moduleFormal Verification In Pilot•Analysis Versus Build tasksFormal verification is considered an analysis task and likeSTA, ATPG etc it is contained in a global analysis Makefile •blocks/<block>/scripts_block/formal/flow_formal.xml © 2006 Synopsys, Inc. (3)This means that by default it does not appear in the StepMakefiles accessed via the GUI•If desired it can be added to the Step build Makefiles so that data promotion is dependent upon successful formal verificationFormal Targets•The flow_formal.gmake Makefiledefines 5 targets –one for each default Pilot Step•Each of these targets calls the sameglobal task script and with the© 2006 Synopsys, Inc. (4)exception of the formal_syn target all task script arguments are identicalReference and Implementation•The formal task differs from other Pilot tasks in that it in effect hastwo sourcesThe reference design is specified by GEV_SRC and is read into acontainer named “r”The Implementation design is specified via GEV_DST and is read© 2006 Synopsys, Inc. (5)into a container named “i” In all default targets we verify the Step input data versus the Stepoutput data•GEV_SRC=inputs •GEV_DST=outputs•Reports and logfiles are written to the GEV_DST rpt and logdirectoriesFormal TEV VariablesOptionally specify file of settings to override Pilot defaultsDefault is “”Specify script used to read both impl and ref designsDefault is $GEV(gscript_dir)/formal/read_designs.tcl© 2006 Synopsys, Inc. (6)Specify script to apply constraints to impl or ref designs Default is GEV(bscript_dir)/formal/constraints_formal.tcl Optionally supply list of file types (verilog, netlist, db etc) to assist in reading the REF design during the syn step Default is “”In default flow is only used in formal_syn target Specify number of CPU’s to be used for verification Default is 1 Note this is only supported with GEV_JOB_DIST=lsfFormality Script Calling Treeread_designs.tcl Optional File –no default value TEV_FM_DESIGNSTEV_FM_SETTINGS If step == syn© 2006 Synopsys, Inc. (7)formal.tclFormal.read_with_file_types.tclconstraints_formal.tcl../work/inputs/generated_type_file.tclLocal ScriptGlobal Script TEV_TCL_TYPE_FILE TEV_FM_CONSTRAINTSformal.tcl•This is the main formal verification script that is specified in the Step MakefileReads TEV variablesDetermines location of hdlin_dwrootSets default formality tool variables (see next slide for details)Sets or overrides additional formality variables via optional TEV_FM_SETTINGS file -default is “”Read s all db’s defined in the link_library variable Creates “r” and “i” containers© 2006 Synopsys, Inc. (8)Reads REF and IMP designs via required TEV_FM_DESIGNS -default is $GEV(gscript_dir)/formal/read_designs.tcl •Save session –$GEV(block).readApplies constraints specified via optional TEV_FM_CONSTRAINTS -default is $GEV(bscript_dir)/formal/constraints_formal.tcl Run match•Save session -$GEV(block).matchPerforms verification and generate reports•If verification fails generate fail points report, guidance report and save session -$GEV(block).verifyDefault Formality Settings## Extract from formal.tcl## Black box behavior is controlled by these two variables:## -hdlin_unresolved_modules (default is "error")## -verification_blackbox_match_mode (default is "any")## For more conservative behavior, set verification_blackbox_match_mode to "identity".set synopsys_auto_setup trueif { $TEV_FM_SETTINGS != "" } {tproc_source -file $TEV_FM_SETTINGS}•By default synopsys_auto_setup is enabled (true) –this results in a certain set of options being set as shown below (reported in the log file)© 2006 Synopsys, Inc. (9) If you do not want these options set as shown below you can override the individual setting in the TEV_FM_SETTINGS file***************************** Synopsys Auto Setup Summary ****************************** !!! Synopsys Auto Setup Mode was enabled. !!!!!! Verification results are valid assuming the following setup constraints: !!!### RTL Interpretation Setupset hdlin_ignore_parallel_case falseset hdlin_ignore_full_case falseset hdlin_error_on_mismatch_message falseset hdlin_ignore_embedded_configuration true### Undriven Signal Handling Setupset verification_set_undriven_signals0:X### Test Logic Setupset verification_verify_directly_undriven_output falseFor details see report_dont_verify_points and report_constants### Clock Gating Setupset verification_clock_gate_hold_mode AnyFor further details on Synopsys Auto Setup Mode: Type man synopsys_auto_setup ****************************************************************************************read_designs.tcl•This is the default global script specified by the TEV_READ_DESIGN variable•If in the SYN or DFT Step then process and read any SVF files availableSee following slides for details, if this is not desired then theappropriate section should be commented out of the scriptFor the SYN step then read reference design by sourcing © 2006 Synopsys, Inc. (10)•$GEV(gscript_dir)/formal/formal.read_with_filetypes.tcl •For all other steps read implementation and reference designs by reading Verilog netlist from GEV_SRC and GEV_DST•Read any hierarchical sub modules of the designSee later slides for detailsread_designs.tcl –UPF Handling•If UPF is enabled then the design’s UPF configuration file will be loadedduring verification in the SYN, DFT, and FP stepsReference Design: load_upf –r $GEV(src)/$GEV(block).upf implementation Design: load_upf –i $GEV(dst)/$GEV(block).upf Exceptions to this are•SYN step RTL reference designread the upf configuration file is that specified by the variable TVAR(config,upf_for_rtl)© 2006 Synopsys, Inc. (11)•FP stepRead $GEV(block).pg.v for the implementation design •PNR/FINISH stepRead $GEV(block).pg.v for reference and implementation designs•If UPF is enabled then the read_designs.tcl script will also use atechnology/design specific procedure (tproc_retention_register_setup)The procedure is defined in the top of this script and must be edited for other designs and technologiesThis procedure is used during the SYN verification to remove retention register designs from the implementation designSVF Files•During the Synthesis step SVF files are generated to assist in formal verificationThese are automatically enabled by the default Pilot synthesis scripts If multiple synthesis runs are made (e.g. additional incremental synthesisruns) then additional SVF files will be produced for each task•During Formal Verification the SVF files are readMultiple files are read based upon a sorted ordering of filepaths andfilenames in the work directories of the syn step© 2006 Synopsys, Inc. (12)•The SVF files contain references to any dwsvf directories that are required so the dwsvf directories are not copied as in previous Pilot versionsIn the default pilot flow this means that the 010, 020 ordering will be followed when reading SVF filesNote that if you are running SYN design explorations in a single directory this may cause verification issues as the multiple files are read•Once you have selected the appropriate flow you should remove the additional (exploratory) SVF files to enable the formal task to complete successfully by just reading the SVF files relevant to your chosen implementationformal.read_with_file_types.tcl•This file is sourced when reading the reference RTLfor verification during the SYN stepSources the file specified by TEV_TCL_TYPE_FILE•Default value is “”•This is set to ../work/inputs/generated_type_file.tcl for the © 2006 Synopsys, Inc. (13)SYN step Makefiles –this is the default file created by the manifest parser during the synthesis setup taskReads the various file types established by sourcing the generated_type_file.tcl script•This works in an similar fashion to the default Pilotelaborate script –it allows a mixture of Verilog, System-Verilog, VHDL, netlists, ddc and db filesHierarchical Designs –SpecifyingSub Blocks•Sub blocks of a design must be specified in the Block Integration section of the GUI (HM) Hard Macros –separately built IP blocks instantiated in design(LM) Logic Macros –bottom up synthesized (and dft inserted) blocks included in top level(SM) Soft Macros –physical sub blocks created during floorplanning•These sub blocks must be identified correctly for hierarchical formal verification to workThey are specified as a list of {block_name instance_name} pairs© 2006 Synopsys, Inc. (14)Hierarchical Verification•Formal verification can be sped up by the use of blackbox models for sub blocks of a design that havealready been verified•The Pilot flow makes use of the hdlin_interface_only© 2006 Synopsys, Inc. (15)setting for any sub blocks used in the designThis is a change from earlier versions of Pilot which explicitlyread “ports only” Verilog modules and used set_black_box commands•Which blocks the parameter is applied to dependsupon the step being executed and the type of the block as defined in the integration section of the GUIReading sub blocks•Hard Macros, Soft Macros, and Logic Macros are handled differently depending upon the Step being ranSYN Step•For both reference and implementation set hdlin_interface_only on all Hard Macro and Logic Macro blocksDFT Step•Same as SYN step © 2006 Synopsys, Inc. (16)FP Step•Entering the FP step we will only have Hard Macros present in a design since logic macros will have been merged into the top level design•For both reference and implementation set hdlin_interface_only on all Hard MacrosPNR/FINISH Steps•During PNR/FINISH we can have Soft Macros generated during the FP step in addition to any Hard Macros•For both reference and implementation set hdlin_interface_only on Hard Macros and Soft MacrosPassing Verification•For a passing verification no additional reports areproduced•The formality log file is included in the task log file© 2006 Synopsys, Inc. (17)Failing Verification•For a failing verification additional files are created to assist indebugging the failureFSS file (save session output) Unmatched points report Failing Points Report © 2006 Synopsys, Inc. (18)Guidance Report•To debug a failing verification you should use the view.fm targetFor example%unix> cd syn/tmp%unix> gmake –f ../../scripts_block/syn/<step_flow_makefile>.gmake view_fm %formality> restore_session../work/outputs/<blockname>.fssFormal Tasks in the GUI•The default Optimize flowsdo not include a formalverification taskExample on left is syn Step•If desired the formal taskcan be included in any of the © 2006 Synopsys, Inc. (19)optimize flow MakefilesIn this way a dependencyupon successful formal verification can be added to the optimize promote targetFormal Tasks in the GUI•In the example we have added a formal task, named syn_formal, to the default syn step •Point to remember:Dependencies between tasks are always specified by the connections in the GUIThe connections also define the default values of GEV(src) and GEV(dst)GEV(src)Data Source© 2006 Synopsys, Inc. (20)•We do not want to run formal until syn task is complete –but also we do not want to read GEV(src) data from the syn taskThe formal task is one of those “special” cases where GEV(src) and GEV(dst) are not the same as the dependenciesHence you must edit the GEV(src) field in the Automation Tab of the formal task to specify the realsource of the input data –which is usually the inputs directory for the formal taskTaskDependenciesFormal Verification Summary •Formal verification is ran as a separate analysis task for each stepIt can be added to the optimize Step optimize targets through the GUI if desired•Pilot provides a default set of scripts that will handle the default © 2006 Synopsys, Inc. (21)flow inside of PilotUsers can customize the scripts to their needsFormal constraints may need to be modified on a per block basis Reading of designs may need to be modified if “non standard” flows are used.•The view_fm target is useful in debugging a failing verification•Last Slide© 2006 Synopsys, Inc. (22)。
NS-3 Python Bindings
NS-3 Python BindingsFrom NsnamMain Page - Roadmap - Current Development - Developer FAQ - User FAQ - ToolsInstallation - Troubleshooting - HOWTOs - Samples(/wiki/index.php/Category:Samples) - Contributed Code -PapersContents1 Overview2 Build instructions3 Testing4 Running programs5 Instructions for wrapping new or changed APIs5.1 The manual way5.1.1 API of existing module changed or added5.1.2 New module5.2 The semi-automatic way5.2.1 Pitfalls5.2.1.1 "invalid use of incomplete type"5.2.1.2 KeyError5.2.1.3 RuntimeError: pygccxml error: unable to find fundamental type with name'__int128_t'.5.2.1.4 ImportError: undefined symbol6 Caveats6.1 Incomplete Coverage6.2 Conversion Constructors6.3 CommandLine6.4 Tracing6.5 Cygwin limitation7 Troubleshooting7.1 OS X problem and resolutionOverviewThe goal of Python bindings for NS-3 are two fold:1. Allow the programmer to write complete simulation scripts in Python () ;2. Prototype new models (e.g. routing protocols).For the time being, the primary focus of the bindings is the first goal, but the second goal will eventually be supported as well. Python bindings for NS-3 are being developed using a new tool called PyBindGen(/p/pybindgen) .The process by which Python bindings are handled is the following:1. Periodically a developer uses a GCC-XML (/) based API scanning script, which savesthe scanned API definition as bindings/python/ns3_module_*.py files. These files are kept under versioncontrol in the main NS-3 repository;2. Other developers clone the repository and use the already scanned API definitions;3. When configuring NS-3, pybindgen will be automatically downloaded if not already installed. Released NS-3tarballs will ship a copy of pybindgen.Build instructionsJust make sure Python development headers are installed (e.g., in debian/ubuntu: sudo apt-get install python-dev), then waf configure and waf build ns-3 as usual. If you are building a ns-3 repository version (rather than official release), you will also need the program bazaar (/) in order to automatically donwload pybindgen (e.g., in debian/ubuntu: sudo apt-get install bzr).If something goes wrong with compiling Python bindings and you just want to ignore them and move on with C++, you can disable Python with:./waf --disable-pythonTesting"./waf check" now also runs some Python unit tests, at the end.To debug the python bindings themselves, Gustavo reports this: "Unfortunately, Python does some memory allocation tricks that valgrind reports as errors. When I want to check Python bindings memory errors, I used a debug python build (configure python with ./configure --with-pydebug --without-pymalloc), and then valgrind works. But with a standard Python binary valgrind will always detect phony errors and we don't want that."Running programswaf contains some options that automatically update the python path to find the ns3 module. To run example programs, there are two ways to use waf to take care of this. One is to run a waf shell; e.g.:./waf --shellpython examples/mixed-wireless.pyand the other is to use the --pyrun option to waf:./waf --pyrun examples/mixed-wireless.pyTo run a python script under the C debugger:./waf --shellgdb --args python examples/mixed-wireless.pyInstructions for wrapping new or changed APIsThe manual wayYou will need to read some PyBindGen documentation (/PyBindGen/) .API of existing module changed or addedSo you have been changing existing NS-3 APIs and Python bindings no longer compile? Do not despair, you can manually edit the bindings API definitions to make them reflect the new changed API.The API definitions are organized as follows. For each ns-3 module <name>, the filebindings/python/ns3_module_<name>.py describes its API. Each of those files have 3 toplevel functions:1. def register_types(module): this function takes care of registering new types (e.g. C++ classes, enums) that aredefined in tha module;2. def register_methods(module): this function calls, for each class <name>, another functionregister_methods_Ns3<name>(module). These latter functions add method definitions for each class;3. def register_functions(module): this function registers ns-3 functions that belong to that module.New moduleIf you are adding a new module, Python bindings will continue to compile but will not cover the new module. To cover a new module, you have to create a bindings/python/ns3_module_<name>.py file, similar to the what is described in the previous section, and register it in the variable LOCAL_MODULES inbindings/python/ns3modulegen.pyThe semi-automatic wayIt is possible to use GCC-XML and PyGccXml to scan API definitions automatically. The API scanner is not perfect, but it gets most of the job done.First you need to install the necessary tools:1. Get CMake (can either build from source or download binaries for windows, linux i386);2. Get GCC-XML (must download from CVS). Instructions are to be found here(/HTML/Download.html) . Note that, as with all CVS versions, stability may vary.This CVS snapshot is known to work: cvs up -D "2009-09-21".3. Download and install pygccxml (/pygccxml/download.html) , version 1.0.0;(To install: python setup.py install);4. Run ./waf configure, to let ns-3 detect the python scanning tools. You should see something along theselines; if not, something is wrong:[...]Checking for Python module pygccxml : okChecking for pygccxml version : ok 1.0.0Checking for program gccxml : ok /usr/local/bin/gccxml Checking for gccxml version : ok 0.9.0[...]Python Bindings : enabledPython API Scanning Support : enabledNow you are ready to scan; run ./waf --python-scan. If all goes well, the files in bindings/python/* should have been updated with new API definitions. Now you can build ns-3 as usual, and new Python bindings are compiled. Pitfalls"invalid use of incomplete type"If you get a "invalid use of incomplete type" compilation error message, like this:[722/796] cxx: build/debug/bindings/python/ns3_module_internet_ -> build/debug/bindings/python/ns3_ debug/ns3/ptr.h: In destructor ‘ns3::Ptr<T>::~Ptr() [with T = ns3::Ipv4Interface]’:debug/ns3/arp-cache.h:50: instantiated from heredebug/ns3/ptr.h:439: error: invalid use of incomplete type ‘struct ns3::Ipv4Interface’debug/ns3/arp-cache.h:40: error: forward declaration of ‘struct ns3::Ipv4Interface’It means that PyBindGen is generating code that makes use of the implicit copy constructor, and the copy constructor does not work with incomplete types. The solution is to make the copy constructor private, then rescan the API.class ArpCache : public Object{private:ArpCache (ArpCache const &);ArpCache& operator= (ArpCache const &);[...]}KeyErrorIf you get a KeyError during bindings code generation, like:File "/home/gjc/projects/ns/ns-3-allinone/ns-3-distributed/bindings/python/apidefs/gcc-LP64/ns3_module_m module.add_class('DistributedSimulatorImpl', parent=root_module['ns3::SimulatorImpl'])KeyError: 'ns3::SimulatorImpl'It is possible that the order of registering module types is incorrect. You should correct the inter-module dependencies in the module's wscript file:- sim = bld.create_ns3_module('mpi', ['core'])+ sim = bld.create_ns3_module('mpi', ['core', 'simulator'])Then re-scan the python bingins (waf --python-rescan).RuntimeError: pygccxml error: unable to find fundamental type with name '__int128_t'.Recent optimizations in the Time class make use of a __int128_t type, which pygccxml is not written to recognize. A simple workaround for this problem is to configure with --high-precision-as-double, scan, then switch back to normal options:./waf configure --high-precision-as-double./waf --python-scan./waf configure [normal options]Alternatively, update pygccxml to svn revision 1844 (/viewvc/pygccxml? revision=1844&view=revision) .ImportError: undefined symbolIf you declare but don't implement a public method, and rescan the bindings, compilation may succeed but you may get a cryptic runtime error such as:./waf --pyrun examples/tutorial/first.pyImportError: /home/user/ns-3-allinone/ns-3-dev/build/debug/bindings/python/ns3/_ns3.so: undefined symbol Command ['/usr/bin/python', 'examples/tutorial/first.py'] exited with code 1This can be fixed by finding the method that exists in the class declaration but that is not implemented, and removing the declaration, and rescanning the bindings.CaveatsPython bindings for NS-3 is a work in progress, and some limitations are know by developers. Some of these limitations (not all) are listed here.Incomplete CoverageFirst of all keep in mind that not 100% of the API is supported in Python. Some of the reasons are:1. some of the APIs involve pointers, which require knowledge of what kind of memory passing semantics (whoowns what memory). Such knowledge is not part of the function signatures, and is either documented orsometimes not even documented. Annotations are needed to bind those functions;2. Sometimes a unusual fundamental data type or C++ construct is used which is not yet supported byPyBindGen;3. GCC-XML does not report template based classes unless they are instantiated.Most of the missing APIs can be wrapped, given enough time, patience, and expertise, and will likely be wrapped ifbug reports are submitted. However, don't file a bug report saying "bindings are incomplete", because we do not have manpower to complete 100% of the bindings.Conversion ConstructorsConversion constructors(/infocenter/compbgpl/v9v111/topic/com.ibm.xlcpp9.bg.doc/language_ref/cplr384.htm) are not fully supported yet by PyBindGen, and they always act as explicit constructors when translating an API into Python. For example, in C++ you can do this:Ipv4AddressHelper ipAddrs;ipAddrs.SetBase ("192.168.0.0", "255.255.255.0");ipAddrs.Assign (backboneDevices);In Python, for the time being you have to do:ipAddrs = ns3.Ipv4AddressHelper()ipAddrs.SetBase(ns3.Ipv4Address("192.168.0.0"), ns3.Ipv4Mask("255.255.255.0"))ipAddrs.Assign(backboneDevices)CommandLineCommandLine::AddValue works differently in Python than it does in NS-3. In Python, the first parameter is a string that represents the command-line option name. When the option is set, an attribute with the same name as the option name is set on the CommandLine object. Example:NUM_NODES_SIDE_DEFAULT = 3cmd = mandLine()cmd.NumNodesSide = Nonecmd.AddValue("NumNodesSide", "Grid side number of nodes (total number of nodes will be this number squa cmd.Parse(argv)[...]if cmd.NumNodesSide is None:num_nodes_side = NUM_NODES_SIDE_DEFAULTelse:num_nodes_side = int(cmd.NumNodesSide)TracingCallback based tracing is not yet properly supported for Python, as new NS-3 API needs to be provided for this to be supported. Bug #127 (/bugzilla/show_bug.cgi?id=127) for details.Pcap file writing is supported via the normal API.Ascii tracing is supported since NS-3.4 via the normal C++ API translated to Python. However, ascii tracing requires the creation of an ostream object to pass into the ascii tracing methods. In Python, the C++ std::ofstream has beenminimally wrapped to allow this. For example:ascii = ns3.ofstream("wifi-ap.tr") # create the filens3.YansWifiPhyHelper.EnableAsciiAll(ascii)ns3.Simulator.Run()ns3.Simulator.Destroy()ascii.close() # close the fileThere is one caveat: you must not allow the file object to be garbage collected while NS-3 is still using it. That means that the 'ascii' variable above must not be allowed to go out of scope or else the program will crash.Cygwin limitationPython bindings do not work on Cygwin. This is due to a gccxml bug: /Bug/view.php?id=7572You might get away with it by re-scanning API definitions from within the cygwin environment (./waf --python-scan). However the most likely solution will probably have to be that we disable python bindings in CygWin.If you really care about Python bindings on Windows, try building with mingw and native python instead. Or else, to build without python bindings, disable python bindings in the configuration stage:./waf configure --disable-pythonTroubleshootingOS X problem and resolutionProblem: I installed pygccxml 1.0.0 and pybindgen 0.14.0, patched bindings/python/wscript to use the newer versions, installed gccxml-devel from ports, and succesfully compiled ns-3. All tests (./test.py) work fine. However, when I try to run a python-example I get a python crash:$ ./waf --pyrun examples/wireless/mixed-wireless.pyWaf: Entering directory `/Volumes/Shared/Projects/ns-3/ns-3-dev/build'Waf: Leaving directory `/Volumes/Shared/Projects/ns-3/ns-3-dev/build''build' finished successfully (1.114s)Fatal Python error: Interpreter not initialized (version mismatch?)Command ['/usr/bin/python', 'examples/wireless/mixed-wireless.py'] exited with code -6Solution: This can be due to the version used to build ns3 is not the same as the interpreter, possibly due to multiple versions of Python on the system. However, it was resolved for this specific OS X case as follows:"We found the problem, it was in Mac OS X "port" system, causing confusion with ns-3 configure script. Adding a symlink /opt/local/bin/python -> /opt/local/bin/python2.6 fixed the issue."Retrieved from "/wiki/index.php/NS-3_Python_Bindings"This page was last modified on 22 December 2010, at 00:42.。
Gautomatch 说明书
Brief Manual of Gautomatch********************************************************************************** Author: Dr. Kai Zhang, MRC Laboratory of Molecular BiologyContact:******************Description: Gautomatch is a GPU accelerated program for accurate, fast, flexible and fully automatic particle picking from cryo-EM micrographs with or without templates.********************************************************************************** Features:∙Fast:typically, 1.5~2.0s with 15 templates, using a good GPU (e.g. GTX 980, Titan X);∙Fully automatic with simple command on entire data sets;∙Convenient and easy to use;∙Flexible: with or without template, suitable for both basic or advanced users;∙Compatible with Relion/EMAN;∙Background correction:automatic correct the gradient background that affects the picking;∙Rejection of ice/carbon: automatically detect non-particle areas and reject them;∙Post-optimization:scripts available to re-filter the coordinates after picking within seconds ∙Accuracy:the users’ satisfaction is the only ‘gold standard’ criterion;Requirement:--> CentOS/Redhat Linux x86_64 (might be problems on Ubuntu or SUSE)--> Any one of the libraries from CUDA 5.0 to 7.5, but do use the right version of Gautomatch according to your CUDA version--> GPU architecture (Compute Capability) >= SM 2.0 or SM 3.0 Findthe web more details about Cuda version, GPU Compute Capability:https:///wiki/CUDA(for lower architecture, <sm2.0, please contact me)********************************************************************************** Program Download :/kzhang/Gautomatch/Gautomatch_v0.50_and_examples.tar.gz (only pre-compiled binary available now; source code to be released soon when other related projects are done; Several examples and suggested commands included)Usage:Gautomatch [options] <micrographs>Basic options: default values, description:--apixM 1.34 Pixel size of the micrograph, in Ångstrom--diameter 400 Particle diameter, in Ångstrom;--T NONE Particle picking templates in 2D MRC stack; auto-generated if not provided; IMPORTANT: read the usage of option --dont_invertT for more information about templates--apixT 1.34 Pixel size of the templates, in ÅngstromAdditional options(not suggested, only try to optimize in difficult cases), default values and description:--ang_step 5 Angular step size for picking, invalid for auto-templates--speed 2 Speed level {0,1,2,3,4}, the bigger the faster, but less accurate. However, Suggested 2 for >1 MDa complex; 1 for <500kD complex; 1 or 2 for 500~1000 kD; 0 not suggested normally, because the 'accuracy' is simply fitting noise, unless for special noise-free micrographs; use 3 for huge virus, but 2 still preferred; probably do not use 4 at all, not accurate in general.--boxsize 128 Box size in pixel, NOT in Ångstrom; By default a suggested value will be automatically calculated by --diameter and –apixM. It will use 1.3X diameter of your particle (by -diameter option). So don’t worry about if not set.--max_dist 300 Minimum distance between particles in Ångstrom; 0.9~1.1X diameter; can be 0.3~0.5 for filament-like. Don’t be confused about the word --max_dist. This was a spelling error. It will be changed in future.--cc_cutoff 0.1 Cross-correlation cutoff, 0.2~0.4 normally; Try to select several typical micrographs to optimize this value. Alternatively, it will be even faster if you use a small value, e.g.0.1, first and then use 'box_' or 'box_' to filter the box files afterwards. Script could be obtained here: http://www.mrc-/kzhang/Gautomatch/Gautomatch_v0.50/scripts/Just run ./box_ Then it will tell you how to use.Ice, contamination, aggregation, carbon edge, sharp gold/metal particles related options.Carbon Edges:--lsigma_cutoff 1.2 Local sigma cutoff (relative value), 1.2~1.5 should be a good range; normally a value >1.2 will be ice, protein aggregation or contamination. Try to decrease or increase it upon the ‘_rejected.box’ file. This option is designed to get rid of sharp carbon/ice edges or sharp metal particles.--lsigma_D 100 Diameter for estimation of local sigma, in Ångstrom; usually this diameter could be 0.5~2.0X of your particle diameter according to several factors. A diameter around 100~400 works best in most cases. Try to decrease or increase it upon the ‘_rejected.box’ file. Using bigger --lsigma_D, normally you should decrease the --lsigma_cutoff. For smaller and shaper high density contamination/ice/metal particles, you could use a smaller --lsigma_D and bigger --lsigma_cutoff.Ice/Contamination:--lave_min -1.0 Local average density cutoff (relative value), any pixel value below that will be considered as ice/aggregation/carbon etc. For 'black' cryoEM micrograph, set this to very small value e.g. -10.0 will not reject any 'black' dots in general. This option mainly rejects the central parts of the ice, carbon etc. which normally have lower density than the particles. Increase the value from -1.0 to -0.5 will reject more ice area, but may also reject your particles. Check the‘_rejected.box’ to check if the parameter is fine or not. Decrease the value from -1.0 to -1.5 will reject less ice area, but may mistake this area as your particles. Check the ‘_rejected.box’ to optimize the best parameter for most of your micrographs.--lave_max 1.0 Local average density cutoff (relative value), any pixel value above that will be considered as ice/aggregation/carbon etc (for contrast inverted ‘white’ micrograph orne gative stain with big write blobs etc.). Normally, it is not useful for micrographs with ‘black’ particles, but might be helpful to get rid of ‘hot’ area. For negative stain micrograph, if it rejects most of the true particles, just use very big value, like 10.0, so that it will not reject anything.--lave_D 400 Diameter for estimation of local average density, 0.5~2.0X particle diameter suggested; However, if you have 'sharp'/'small' ice or any 'dark'/'bright' dots, use a smaller value will be much better to get rid of these areas. It is quite similar to --lsigma_D, if you use bigger --lave_D, usually it is suggested to use smaller value of --lave_max(e.g. from 1.0 to 0.8) or bigger value of --lave_min (e.g. from -1.0 to -0.5) according the purpose.--lp 30 Low-pass filter to increase the contrast of raw micrographs, suggested range 20~50Å. For bigger particles, use bigger low-pass will work better, smaller particles, use a bit smaller low pass, but <20 Å low pass is not suggested because there is no usable information due to CTF. You could use Gctf to do a phase flip first and use higher resolution for picking. But this is NOT suggested in general! First, it risking in the so-called ‘Einstein noise’ to pick more background.Second, if you cannot properly pick the particle using lower resolution. That means the contrast is in big problem and the reconstruction will be not reliable in general.--hp 1000 High-pass filter to get rid of the global background of raw micrographs, suggested range 200~2000Å. Don’t worry about this option. Gautomatch has its approach to estimate and get rid of the background within the program anyway.I/O options(use these for initial learning and diagnosis, no need for for the final jobs on whole-datasets ):--write_ccmax Specify to write out cross-correlation files--write_pf_mic Specify to write out phase-flipped(pf) micrographs(mic)--write_lave_mic Specify to write out estimated background(bg) of the micrographs(mic) --write_bgfree_mic Specify to write out background subtracted (bgfree) micrographs(mic) --write_lsigma_mic Specify to write out local sigma (lsigma) micrographs(mic)--write_mic_mask Specify to write out the auto-detected mask (ice, contamination, aggregation, carbon edge etc.) by --lsigma_cutoff or --lave_max or --lave_max--do_unfinished Specify to autopick the unfinished micrographs--dont_invertT Whether to invert template contrast. VERY IMPORTANT By default, the program will invert the 'white' templates to 'black' before picking. Specify this option to avoid contrast inversion if the micrographs and templates have the same contrast--extract_raw Specify to extract particle from raw micrograph--extract_pf Specify to extract particle from phase-flipped micrograph; will write a new stack and will not overwrite raw particle stack--gid 0 GPU id, normally it's 0, use gpu_info to get information of all available GPUs.Examples:Gautomatch --apixM 1.58 --diameter 300 Micrographs/Falcon*.mrc (auto-generated templates for 'black' cryoEM micrograph)Gautomatch --apixM 1.08 --diameter 300 --T templates.mrcs --apixT 2.16 Micrographs/Falcon*.mrc(for 'white' templates and 'black' micrograph)Gautomatch –apixM 1.08 --diameter 300 --T templates.mrcs --apixT 3.2 -dont_invertT Micrographs/Falcon*.mrc(for 'black' templates and 'black' micrograph)Gautomatch --apixM 1.08 --diameter 300 --boxsize 360 --write_bgfree_mic -write_lsigma_mic --extract_raw --write_ccmax Micrographs/Falcon*.mrc(suggested for manual diagnosis using the different types of output micrographs)More Examples and suggested commands:/kzhang/Gautomatch/Gautomatch_v0.50/examples/Useful scripts:/kzhang/Gautomatch/Gautomatch_v0.50/scripts/-------------------------------------------------------------------------------------------------------------------------------General Tips:A better way is you split the entire datasets into several groups (e.g. 3-5) with similar appearances, and then optimize the parameters for each group.It is suggested to run it outside the Micrographs/ directory to match typical Relion style.There are several script that you can convert the .box file to reliant .star file. Using these script will be very helpful for the optimization of parameters, checking results, post-filtering the coordinates etc./kzhang/Gautomatch/Gautomatch_v0.50/scripts/There are several I/O options that you can use to understand more about how Gautomatch works and also greatly help for troubleshooting or manual diagnosis and improvement of parameters.Tips about CTF:It is perfectly fine to use raw micrograph (before CTF correction) for particle picking since 30~50Å is sufficient to auto-pick the particles. Usually for the micrograph with defocus around 2-5um, the first 'zero-node' is around 20~30Å; So it is not useful to do CTF correction in general.However, you can use 'Gctf' to automatically determine CTF and flip the phases before picking.Fully CTF correction on micrograph or applying full CTF on templates is NOT suggested, because these operation is normally targeting for high resolution and performed in the last step during/after reconstruction.Since particle picking is basically 'low-resolution' operation, higher resolution will only introduce more false picking and template-bias, known as the so-called 'Einstein noise' -------- A most risking thing in cryo-EM field for beginnersTips about '--dont_invertT' option:This option is very important! By default, the program will invert the 'white' templates to 'black' before picking. This is because our cryoEM micrographs are usually 'black' and 2D averages are'white'.Specify '--dont_invertT' to avoid the contrast conversion if your micrographs and templates have the same contrast (either black or white).Note that the auto-generated templates is ALWAYS 'white' Guassian blob, so for 'black' cryoEM, you should use default.For 'negative stain' +'auto-templates', you should specify '--dont_invertT' so that the auto-generated templates and micrographs are both 'white'.Tips about '--speed' option:Suggested 2 for >1 MDa complex; 1 for <500 kD complex; 1 or 2 for 500~1000 kD; 0 not suggested, because the 'accuracy' is simply fitting noise, unless for special noise-free micrographs; use 3 for huge virus, but 2 still preferred; probably do not use 4 at all, not accurate in general.In theory, a smaller value for --speed will generate a more accurate picking. But this is NOT true, because the meaning of ‘accuracy’ always risk in the situation of ‘higher noise’. So actually, --speed 2 works best in most cases because and --speed 1 might be better for smaller particles.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
AutomaticInter-proceduralParallelizationRavichandhranK.M,Bhaskar.P,Annamalai.S.PandDr.A.P.ShanthiDepartmentofComputerScience,CollegeofEngineering,Guindy,AnnaUniversity
AbstractInthispaper,weintroduceanoveltechniqueforautomaticparallelizationofindependentprocedures.Ourproposedtechniqueidentifiesthepotentiallyindependentprocedurecallsandgeneratescodeforexecutingtheminparallelwithouttheinterventionoftheprogrammer.Ourmajorconcernistoparallelizethosefunctioncallsthatconsumeasignificantportionoftheexecutiontimelikerecursivefunctioncallsandfunctionscallsinsidealoop.Theproposedtechniqueusesahybridapproach,whichinvolvesbothstaticanddynamic(orruntime)analysis.ToreducetheoverheadofspeculativeruntimeanalysisweextendatechniquecalledSensitivityAnalysis(originallydevelopedforloops)torecursiveprocedures.IfaprocedurecallisidentifiedasacandidateforparallelexecutionthenOpenMPconstructsforexecutingthefunctioncallinparallelaregenerated.GeneratingOpenMPconstructshastwomajoradvantages,firstlyitmakestheprogrameasytounderstandanddebug.Secondlyitincreasestheportabilityoftheprogram.
I.IntroductionTheincreasingpopularityofmulti-corearchitectureshavegreatlyincreasedtheavailabilityofparallelhardwareresourcebutatthesametimehasincreasedtheneedfordevelopingparallelsoftwarethatcanexploittheavailableparallelhardware.AsRe-engineeringtheexistingprogramtomakeuseoftheparallelhardwareisbothtime-consumingandexpensive,softwarethatcouldeffectivelyparallelizethesequentialprogramsistheneedofthehour.Moreover,suchanauto-parallelizerwillfreeaprogrammerfromconcentratingonwritingparallelprogramsandallowhimtothinkinhisownnaturalway.Unfortunately,theexistingautomaticparallelizationtechniquesarenoteffectiveenoughtoreplacemanualparallelization.Onereasonfortheineffectivenessisthatmostoftheexistingtechniquesconcentrateonparallelizingtheinstructionswithinasingleprocedureanddonottrytoexploittheparallelismexistingbetweentheprocedures.Thoughafewtechniquesdoso,theyfailtoperformindepthanalysisandalsosufferfromseriousdrawbackssuchasincreasedanalysisoverhead,increasedexecutiontimeincaseofsequentialexecutionandsoon.Tocountertheaboveproblemsweproposeatechniqueforperformingadvancedinter-proceduralanalysiswithminimumoverhead.
II.RelatedWorkAgreatdealofpreviousresearchinautomaticparallelizationhasbeendirectedtowardsparallelizingloopsandrecursivefunctioncallsindivide-and-conquerprograms[1].ManishGupta,SayakMukhopadhyayandNavinSinhahaveproposedatechniquethatusescompile-timeanalysistodetecttheindependenceofmultiplerecursivecallsinaprocedure.Theyhavealsoproposedspeculativerun-timetechniquestoallowparallelizationofprogramsforwhichcompile-timeanalysisaloneisnotsufficient.RuginaandRinard[2]haveindependentlydevelopedsimilartechniquestoautomaticallyparallelizedivide-and-conquerapplications.Theyachieveroughlysimilarresultsbutdidnotperformanyspeculativeanalysis.Boththesetechniquesareeffectiveonlyfordivideandconquerprograms.ThetechniquethatweproposeperformsadvancedprogramanalysistoidentifyandparallelizeregionsintheprogramwhichconsumessignificantamountofexecutiontimebutatthesametimereducestheruntimeoverheadusingSensitivityAnalysis(SA).SAwasoriginallydevelopedforloopsbySilviusRusetall.[3].SensitivityAnalysis(SA)isatechniquethatcomplements,andintegrateswith,staticautomaticparallelizationanalysisforthecaseswhenrelevantprogrambehaviorisinputsensitive.WhenSAisextendedforrecursivefunctionsitcangreatlyreducetheconditionsthatneedtobeevaluatedatruntime.
III.ProposedWorkOneofthemajorhurdlesininter-proceduralparallelizationisthecomplexinterleavingofthefunctioncalls.InaflexibleanduserfriendlyprogramminglanguagelikeC,thereisnolimittotheamountofinterleavingbetweenthefunctioncalls,forexampleanynumberoffunctionscanbecalledinsidealoopandeachofthesefunctionscaninturncontaincallstosame(recursive)orotherfunctionsandsoon.Moreover,insomecasestherecursionisnotimmediatelyobvious,forexampleafunctionXcancallafunctionYwhichonceagaincallsthefunctionX.Fortheabovementionedreasonsourtechniqueperformsadetailedanalysisoftheprogramflowtofindthepotentialregionsintheprogramthatconsumessignificantamountofexecutiontime.OncethepotentialregionsareidentifiedtheyareanalyzedforparallelismusingSymbolicArraySectionanalysis[1]andStaticanalysistechniques.Incasetheinputdefiescompile-timeanalysis,speculativerun-timeapproachescoupledwithsensitivityanalysisisused.Thus,theproposedtechniqueconsistoftwophases,
AnalysisPhaseInthisphaseafunctiondependencygraphisconstructedandthepotentialcandidatesforparallelizationaredetermined.DirectandIndirectRecursivefunctions,functioncallswithinaloopareexamplesofpotentialcandidatesforparallelization.Oncethecandidatesareidentified,staticcompile-timeanalysistechniqueslikeSymbolicArraySectionanalysisareapplied.Iftheyarenotsuccessful,thepredicates(orconditions)thatneedtobesatisfiedfortheparallelizationtosucceedaredetermined.ThesepredicatesarethensimplifiedusingSensitivityAnalysis.Oncetheparallelproceduresandtheminimalpredicatesetaredeterminedtheyarestoredinaconvenientdatastructure.