summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGabe Black <gabeblack@google.com>2018-09-22 08:05:16 -0700
committerGabe Black <gabeblack@google.com>2018-10-16 00:31:55 +0000
commit9c56d8adfe5c1f9cb28842a0b9f83873db1ab22f (patch)
tree658b6e5cec5b5d2fa49921ee94cb4c2a19857a63
parent7fa683ada5cb84ac9f5c20e82e642b14161ffedb (diff)
downloadgem5-9c56d8adfe5c1f9cb28842a0b9f83873db1ab22f.tar.xz
systemc: Simplify sc_time_stamp().
sc_time is now inherently based on properly scaled Ticks, so there's no reason to try to scale it to be in picoseconds, especially since the scaling factor may be unreliable if the timescale hasn't been fixed yet. Change-Id: I28baeb9792e81e1d00f6f37672df435766311864 Reviewed-on: https://gem5-review.googlesource.com/c/12974 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com>
-rw-r--r--src/systemc/core/sc_main.cc8
1 files changed, 2 insertions, 6 deletions
diff --git a/src/systemc/core/sc_main.cc b/src/systemc/core/sc_main.cc
index 735fb0c1b..e9df6a1e0 100644
--- a/src/systemc/core/sc_main.cc
+++ b/src/systemc/core/sc_main.cc
@@ -250,12 +250,8 @@ sc_stop()
const sc_time &
sc_time_stamp()
{
- static sc_time tstamp;
- Tick tick = ::sc_gem5::scheduler.getCurTick();
- //XXX We're assuming the systemc time resolution is in ps.
- // If tick is zero, the time scale may not be fixed yet, and
- // SimClock::Int::ps may be zero.
- tstamp = sc_time::from_value(tick ? tick / SimClock::Int::ps : 0);
+ static sc_time tstamp(1.0, SC_SEC);
+ tstamp = sc_time::from_value(::sc_gem5::scheduler.getCurTick());
return tstamp;
}