systemc: Fix the time resolution when constructing an sc_time.

This is (sort of) mandated by the spec. More specifically the spec says
that the systemc API for changing the time resolution can only be
called once, and can only be called before a non-zero sc_time is
constructed.

Because sc_time can be constructed during elaboration and the gem5
version of time resolution is generally not locked down until the
actual simulation starts (after elaboration), the sc_time constructor
needs to call the fixing function itself to ensure that, for instance,
the scaling factors for various real life time units within gem5 are
initialized.

Change-Id: Ied4b43659834761b55b5ae49ea62779af891d9e3
Reviewed-on: https://gem5-review.googlesource.com/12037
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

diff --git a/src/systemc/core/sc_time.cc b/src/systemc/core/sc_time.cc
index 002121e88f6d0ee618d6a2bcf860bb0f47b757ca..f51b1581c51a1b4446ffb41724f33c16cf898186 100644 (file)
--- a/src/systemc/core/sc_time.cc
+++ b/src/systemc/core/sc_time.cc
@@ -28,6 +28,7 @@
  */
 
 #include "base/logging.hh"
+#include "python/pybind11/pybind.hh"
 #include "systemc/ext/core/sc_time.hh"
 
 namespace sc_core
@@ -54,6 +55,19 @@ double TimeUnitScale[] = {
     [SC_SEC] = 1.0
 };
 
+void
+fixTimeResolution()
+{
+    static bool fixed = false;
+    if (fixed)
+        return;
+
+    auto ticks = pybind11::module::import("m5.ticks");
+    auto fix_global_frequency = ticks.attr("fixGlobalFrequency");
+    fix_global_frequency();
+    fixed = true;
+}
+
 } // anonymous namespace
 
 sc_time::sc_time() : val(0) {}
@@ -62,6 +76,7 @@ sc_time::sc_time(double d, sc_time_unit tu)
 {
     val = 0;
     if (d != 0) {
+        fixTimeResolution();
         //XXX Assuming the time resolution is 1ps.
         double scale = TimeUnitScale[tu] / TimeUnitScale[SC_PS];
         // Accellera claims there is a linux bug, and that these next two