First of all, we explained the performance of our parallel simulation algorithm. After we tested its first version with aiger benchmarks, we received worse results than our sequential algorithm. Than, we told which optimization techniques we applied in order to make it faster than sequential one.

Secondly, we made some assumptions in our parallel code to run on some specific input files correctly, then we decided to generalize them, and make our simulation code work efficiently with every input file.

Thirdly, we discussed benefits of random input generation for our net-lists in the code instead of reading these inputs from an input file. Then, we concluded that this change will remove some overhead on simulation code.

Finally, we talked about extra optimization operations that we can apply our code and how these changes may affect simulation time. Then, our supervisor made some comments about progress and posted us some new large benchmarks.

Up to next meeting, we are going to deal with new optimizations, tests, and we are going to upgrade our simulation code.

In this week, we have worked on improving our algorithm most of the time. We had implemented the last parallel version of our code by using CUDA architecture. This time, we focused on optimization features that this architecture provided us.

First of all, we built our special clusters for blocks. Then, we controlled that the distribution of gates into these clusters were balanced or not for some test net-lists. Then, we left a number of levels at the top part to be executed by a single block. After arranging the clusters and blocks, we made a number of tests with both parallel and sequential version of code.

At the beginning, we got very bad results for parallel version when it was compared with sequential one. Then, we had to make certain optimizations. As memory optimizations increased in our code, we saw that time of parallel simulation decreased very much. In order to make optimizations in the code, we were quite careful in analyzing our code.

During next week, we will continue with optimization work and try new techniques.

Melih Mert

First of all, we tried to understand the logic of Aiger simulation code. This was really important for us to know which techniques were used in this simulation. After understanding its details, we wrote our sequential simulation code which worked very fast when compared with the previous versions. Then, we parallelized this code. However, we had another inconsistency in output values. The reason of this is that we could not synchronize threads in different blocks in CUDA architecture. So we should find another method for parallel version.

Finally, we implemented different kernels for distinct tasks. This helped us to provide a safe and correct synchronization mechanism. Then, we tested our simulation code with some net-lists. Then, we decided that we had to work on it in more detail.

During next week, we are going to work on improving our last parallel simulation algorithm.

Melih Mert

In our algorithm, we firstly levelized gates. After that, we divided gates into clusters by making all of them independent from each other. Then, we simulate and gates, after that we simulate latches for all cycles.

The most time consuming part was the optimization part of our code. To do this, we analyzed our code to be able to decide where we could use shared memory instead of global memory. After we made use of shared memory in some of our code, we decreased time to run to nearly 60% of the recent week’s result.

In the next week, we are planning to make further optimizations to make our result better than the sequential part.

Murat Bozkurt

After that, we analyzed the AIGER simulation code and understood our mistake. Then, we started to write our new algorithm. Again, this new algorithm is based on levels which provide necessary independence for parallelism. Then we wrote two distinct kernels, the first one is for simulating the and gates and the other one is for simulating the latches.

After writing our algorithm, we realized that it did not behave as we expected. After some researches, we found out that CUDA does not allow block synchronization. To make blocks sychronized, we should use different kernels. Launching new kernels implicitly synchronize blocks. So, we should think a new parallel algorithm on our latest correct sequential algorithm.

We implemented a new parallel algorithm but it had a very bad performance initially.

In the next week, we are planning to increase our algorithm’s performance by considering CUDA optimization techniques.

Murat Bozkurt

- First we determine a level in which there are at least 30 gates. This number then will be used as block number. (This determination is generic, in other words, we can change it to 40 or 50 to see if increased number of blocks will result in better performance)

- After determining the relevant level, we start going back from each of the and gates in that level and construct a triangular shape.

- In the base of that triangle, there are the inputs and in the rightest part there is the single output.

- When determining this triangular shape, we copy the necessary gates for each block, so that the blocks become independent from each other.

- We try to leave the number of gates coming after the determined level low so that they can be simulated by just one block. (If we did not ensure this, we would again need to deal with explicit block synchronization which does not operate correctly every time.)

- After implementing this algorithm we started to make some time efficiency control. At the beginning the method worked quite inefficient(slower than the sequential version). However, after this observation, we started to use the techniques that CUDA offers us. Those include mostly memory optimizations.

- We should make the need for global memory as less as possible since reaching to device global memory is a quite expensive operation. We traced our code and made optimizations based on this phenomenon. Then, we observed an increase in time efficiency. However, the level is still not as good as we expect.

Next Goal: During the next week we will work on optimizing this method further since this method promises more ways for optimization. And we also begin to use the test cases coming from sparc and opencore.

Barış Akşanlı

After this observation, we began to investigate the simulation code of AIGER itself and achieved to understand the specific structure of AIGER itself. Then we rewrote our simulation algorithm in correspondence with this simulation algorithm of AIGER itself. After finishing the implementation, we saw that the new sequential code works really fast. So this has explained the reason why AIGER simulation works quite fast even for big input data.

After seeing that the old global level-local level logic is wrong, we constructed a new parallelism method for the newly generated sequential algorithm. This method again includes a level based simulation. The base for level is required to construct the necessary independence for parallelism. Then we generated two distinct kernel functions, one for simulating the and gates and the other for simulating the latches.

We planned to perform the and gate simulation in one kernel. And obtained good timing results at first. However, when we wanted to validate the answers, we saw that there are some inconsistency between the AIGER answers and ours. So, we debugged our code and realized that the technique we used for block synchronization is not working as we want. This made us to make a detailed search about the block synchronization in CUDA and the fact that we learned is that there is no way to synchronize the blocks in CUDA. The only way to synchronize the blocks is to divide the kernel into multiple parts so that the block synchronization can be handled implicitly by CUDA architecture.

Then we divided our kernel into different parts and we were able to validate the correctness of the answers in parallel execution. However, in this time the time efficiency decreased dramatically, such that we obtained 4 times worse results. We tried to use some properties of CUDA architecture in order to increase the performance, however the time efficiency did not improve as we want.

So, this situation made us to develop another algorithm for parallel simulation. Since we did not want to divide the kernel into multiple parts, we should construct the independence between the blocks(as we can not synchronize them manually). This method includes the duplication of the gates that shall be used by more than one block. In this method, we will generate more blocks and use them efficiently.

Next Goal: We will start to implement the new parallel algorithm and test it in terms of correctness and time efficiency.

Barış Akşanlı

- Correcting bug in our first version of code

- Adding new functions on the new implemented version of our code

First of all, there were bugs in our first code and I tried to find them using benchmarks from AIGER web-site. That requires debugging the code and detecting the bug. After detecting it, I corrected some of these bugs.

After that, I worked on our code’s new implementation which was done using linked lists instead of arrays. It requires additional functions and I worked on writing them.

In addition to these, I worked on parallelization of our code’s second version. Parallelization part of two versions are very similar but we had to make some modifications on them. Also, we made some optimizations on them for better efficiency.

In the next week, I will work on parallelization of our code and try to make it fully functional.

Murat Bozkurt

Firstly, I have spent most of my time in designing and testing the parallelization code that we have written for our simulation algorithm.

Secondly, there were certain problems in some parts of the code, and I tried to find the source of these bugs.

In order to design a parallel code for our simulation algorithm, all synchronization issues must be considered carefully before starting coding. All threads in all blocks that are active in kernel access some memory locations in our structures. Therefore, concurrent read and write shall not be allowed for the same location in our kernel. I have worked basically on this.

Then, I have spent some time on debugging our code in order to check efficiency of our search and traversal algorithms, and how they perform if a deep net-list was taken as input. Then, I saw that this linked list structure performs quite well in doing these operations, whereas our previous structures degrades the performance dramatically.

In addition, we delivered our third interim report of the project to our supervisor.

Next week, I am going to concentrate more on our code as a whole. I will make a number of tests aiming to detect any possible error.  In addition, performance of our parallel simulation shall be compared with other simulation tools.

Melih Mert

- Rewriting of our cycle based simulation with using linked list representation.

- Updating and correcting the first kernel written before.

I firstly focused on establishing a new data structure that shall keep the netlist of a given circuit. Last time, we were using arrays to keep the netlist information. However, we examined our implementation and saw that that implementation is not efficient enough particularly if we used huge netlists. The main reason is that we could not keep the connection information properly with arrays. Then, we decided to construct a linked list. With this, we would be able to keep the connection information of each node. Also, with linked list implementation, the graph traversals have become easier and more efficient since we then knew where to go after examining an and gate or a latch. After finishing the implementation, we observed that this way is much better than the old implementation.

After finishing the implementation of the new way, I tried the new code with some benchmarks from AIGER web-site to validate our implementation.

Then, I finally came to alter the kernel code. Actually, there were not many changes in the kernel resulting from our new implementation. However, we also tried to improve the code quality and the efficiency of the kernel written before. Then we ran the code firstly in our own machines with the emulator facility provided by NVIDIA. However, there are still some concurrency problems that we should handle before we claim a successful conclusion.

Next Goal: In this week, the main concentration will be on correcting the kernel and making it to opearte fully functional. Then we shall check the validity of the source code and verify it. The last part, of course, includes testing with benchmarks provided in AIGER’s website.

Barış Akşanlı