Parallelized Critical Path Search in Electrical Circuit Designs

More documents

Recommendations

Info

to be done. In addition, the insertion of new elements to the result list is not applicable. 4. The Arc-Flag Approach The Arc-Flag approach [16] presumes that a graph has already been divided into partitions. It is irrelevant which of the partitioning methods has been used to perform the partitioning. The Arc Flag approach calculates all shortest paths for each possible entry point into a region to all possible exit points. The path to the exit and the name of the exit point is stored at each entry point. This annotation is called the arc to the exit. The arcs can be created dynamically. Each time a shortest path calculation is performed and a path through a region from a new entry point is requested, this shortest path is calculated and stored at the entry point. If a shortest path calculation enters a region again at a point where the shortest path through the region has been calculated before, then the stored path is used. This saves a lot of calculation time, because the shortest path search through this partition will not perform again. From time to time, more and more paths will be cached. The more shortest path calculations are performed, the more speed-up can be achieved. The calculation of the arcs can also be performed as a preprocess to the actual shortest path calculation. As a result, all shortest path pairs through a partition are already known when a shortest path search on the graph is performed. 4.1. Preprocessing the Graph Preprocessing a graph is needed to calculate and store the Arc-Flag entries for each region of a static partitioned graph. Therefore, a one-to-all shortest path computation using a standard Dijkstra algorithm (all-pairs shortest-path) is performed. This Dijkstra run can be interrupted if all nodes in a region are marked as visited. In the worst case scenario, (n nodes and m pairs) the complexity is: O(m(m + n + n log n)) with m = O(n) this will result in: O(n 2 log n). For large n, it is obvious that this preprocessing takes far too long. There are two possible solutions suggested by Moehring et al. [16]. First, they showed that it is possible to preprocess the graph without calculating all-pairs of shortest paths. Finally, the storage of pruned shortest path trees can help to avoid this complexity problem. 4.2. Two-Level Partitioning Arc Flag Approach Using one of the partitioning methods mentioned earlier, in combination with the Arc Flag approach and preprocess- Figure 3. Coarsing ing the graph, the region containing the target node can be reached very fast. However, inside the target region, the path from the entrance point to the target node needs to be found by a separate search. Depending on the granularity of the partition and the size of each region, such a search may need to visit many nodes in the region where the target belongs to. To avoid this bad behavior, two partition levels can be used. The first partition level is a coarse level while the second one is a detailed level. As an optimization, the detailed level could be stored only for heavy loaded regions. In Figure 3, a 5 × 5 coarse partition and a 3 × 3 fine partition for each coarse partition is used. Coarsening and storing detailed levels is more memory efficient than using a 15 × 15 grid in this case. 5. Experiment In this section, we evaluate three methods: bidirectional search, reachable function and our adapted Arc-Flag approach. We compare them against a base algorithm, i.e. the standard Dijkstra algorithm. The bidirectional search is chosen because it is a very simple method, whereas the reachable function is compared due to its fast runtime. In addition, we compare Intel C++ compiler [10] (Intel- 10.0.023) that supports auto-parallelization with gcc version 3.4.6. For the test environment, we use an Opteron server with two Dual Core AMD Opteron processors (275 HE) with 2.2 GHz. Thus, four CPU cores available for calculations. This machine is equipped with 16 GB of physical main memory. From each core, all the available memory can be accessed. The available hard disk space is adding up to 1 TB mirrored using a RAID level 1. As for the operating system, a 64-bit Red Hat Enterprise Linux Workstation version 4 (update 4) is installed. For the test data, we use the freely available chip design, i.e. the Verilog’s register transfer level (RTL) description
of the Sun’s OpenSPARC T1 (Niagara) processor [18]. The data represent a large graph of an electrical circuit. 5.1 Test Method A RTLvision Pro program [19] is used to implement the algorithms and the shortest path extraction. Listing 1 shows the script used to start and measure the shortest path extraction. It is written in a Tcl/Tk like language which is used to customize and program RTLvision PRO with user defined functions called Userware. After reading the OpenSPARC RTL test data with the RTLvision PRO software, a synthesized netlist with a gate equivalent of over 30 million gates is produced. Particularly this results in a graph with 31,593,068 vertices and 160,617,454 edges. s e t db [ zdb open −readonly / tmp / T1.zdb ] s e t i n P o r t {} s e t o u t P o r t {} s e t t o p {} $db foreach t o p t o p break $db foreach p o r t $top p o r t { s w i t c h [ $db d i r e c t i o n O f $ p o r t ] { ‘ ‘ i n p u t ’ ’ { lappend i n P o r t $ p o r t } ‘ ‘ i n o u t ’ ’ − ‘ ‘ o u t p u t ’ ’ { lappend o u t P o r t $ p o r t } } } foreach s t a r t P o r t $ i n P o r t { foreach e n d P o r t $ o u t P o r t { s e t t [ time { s e t r e s [ $db cone −out − t a r g e t O b j $ e n d P o r t $ s t a r t P o r t ] }] s e t t [ l i n d e x $ t 0] s e t t [ expr {round ( $ t / 1000 . 0 ) } ] ; # ms s e t t [ expr { $ t / 1000 . 0 }] ; # s e c o n d s puts ‘ ‘ $ s t a r t P o r t t o I /O\ t $ t \ t [ l l e n g t h $ r e s ] ’ ’ } } $db c l o s e Listing 1. A script running the all-pairs path extraction. At the start point, each top level input port is selected. The end point of the path extraction on the netlist database is one of the output ports. Thus, from each top level input port a shortest path extraction to all output ports is performed. The time needed to extract all paths between all Figure 4. Runtime of the Intel icc compiler compared to the gcc compiler. input and output port pairs is measured using the Tcl time command which returns the CPU time for a command in microseconds. This kind of test is - compared to the real usage - somehow artificial but it is the worst case scenario. No longer running path extraction on the circuit can be performed, because the extraction starts at a top level input port and ends at a top level output port. In addition, the implementation of the Dijkstra algorithm is highly recursive. Due to this fact, the program exhaustively uses stack memory during the runtime. In order to run this test script without an out of stack memory error, the operating system limits need to be adjusted with the u l i m i t −s u n l i m i t e d command. During the tests a stack memory consumption of about 2 GB was measured. 5.2. Experiment Results 5.2.1 Auto-Parallelizing Intel offers a commercial compiler with an auto parallelization option [10]. Based on a static source code analysis, the Intel compiler promises to create code that run as parallel threads and takes the advantage of multi-core CPUs. Depending on the complexity of the source code and on the number of independent loops, a significant speed-up can be expected. Therefore, we first look into how the Intel icc compiler can offer such benefit with zero effort. For the comparison of the Intel’s icc compiler against the GNU’s gcc compiler, the existing path extraction code without any optimization for parallel execution is used. The
Page 1 and 2: Parallelized Critical Path Search i
Page 3: 3.1. Static Partitioning of Graphs
Page 7 and 8: Figure 6. Runtime of the reachable

Parallelized Critical Path Search in Electrical Circuit Designs

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?