Fixes for atomic coalescing at L1, correlated with QV100 hardware

[abhaumick]

• fixed atomic coalescing at L1

  • modified warp_inst_t::memory_coalescing_arch_atomic()
  • behavior correlated with QV100 hardware

• modified trace.h

  • added DPRINTF_RAW() to allow prints without gpu_sim_cycle
  • for prints from classes that do not have a gpu_sim_cycle or gpu_tot_sim_cycle variables used by DPRINTF

• added config option gpgpu_shmem_atomic_warp_parts

  • added to option parser (default value: 2)
  • updated QV100 config

• added trace streams

  • ATOMICS
  • ATOMICS_DETAIL

• resolves mismatch reported in Meeting Minutes -- 3/20/20

  Benchmark 2 (Atomic bandwidth to the same address)
  atomic_add_bw_conflict:

  cycle error = 1554% (Sim/HW cycles = 16.5X) so simulator is 16.5X slower than HW.
  HW l2 atomics = 10240, Sim l2 atomics = 163840

  In the microbench, we generate atomic accesses wherein all threads access the same memory region.
  We generate 163840 threads, each executes 1 time (so total atomic insts = 163840)

  It seems in gpgpu-sim, it serializes the accesses to the same region, while the HW coalesce these accesses into 16 threads group.
  We can fix the simulator to coalesce conflict accesses into 16 threads, this may alleviate the problem here.
  A relatively simple change to "memory_coalescing_arch_atomic" in abstract_hardware_model.cc should fix this.

[cesar-avalos3]

Correlation of atomic ubenches does not look significantly better compared to the latest (as of this review) dev branch of GPGPU-sim, atomic_add_bw_diverge still off by a lot. Code makes sense though.
Still waiting for the feedback of the other reviewers, and the original author.

Worse in SASS

[tgrogers]

This has been lingering a long time.

@abhaumick , @cesar-avalos3 can you update me on the current state here?

Several years ago, when we checking the accuracy of the atomics we had a set of uBenches that tested latency and BW when warps were updating both the same address and different addresses. From what I remember the results were a disaster.

@abhaumick spent a non-trivial amount of time trying to fix this. And I think this PR is the results of that time.

Do we have uBenches in the regressions that test the atomics? I certainly remember a long email chain about our volta atomic correlations.

[tgrogers]

I think this code was a good fix.
@abhaumick - do we have some uBenches that test this at least? If so, we can take it from here.
@cesar-avalos3 - where is the correlation data you said this fix mnade worse?