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