mem: Fix latency handling in MemDelay

MemDelay wouldn't consume pre-existing delays in the packet and
therefore the latency it adds would overlap with them. This patch
fixes the MemDelay to properly account for them.

Change-Id: I7330fbf1c8161a21523a0b4aab31c72e34bce650
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30055
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit is contained in:
Nikos Nikoleris
2020-05-13 15:44:35 +01:00
parent d3024accaf
commit 35d9bf99a8

View File

@@ -1,5 +1,5 @@
/*
* Copyright (c) 2018 ARM Limited
* Copyright (c) 2018, 2020 ARM Limited
* All rights reserved
*
* The license below extends only to copyright in the software and shall
@@ -87,7 +87,12 @@ MemDelay::MasterPort::MasterPort(const std::string &_name, MemDelay &_parent)
bool
MemDelay::MasterPort::recvTimingResp(PacketPtr pkt)
{
const Tick when = curTick() + parent.delayResp(pkt);
// technically the packet only reaches us after the header delay,
// and typically we also need to deserialise any payload
const Tick receive_delay = pkt->headerDelay + pkt->payloadDelay;
pkt->headerDelay = pkt->payloadDelay = 0;
const Tick when = curTick() + parent.delayResp(pkt) + receive_delay;
parent.slavePort.schedTimingResp(pkt, when);
@@ -136,7 +141,13 @@ MemDelay::SlavePort::recvAtomic(PacketPtr pkt)
bool
MemDelay::SlavePort::recvTimingReq(PacketPtr pkt)
{
const Tick when = curTick() + parent.delayReq(pkt);
// technically the packet only reaches us after the header
// delay, and typically we also need to deserialise any
// payload
Tick receive_delay = pkt->headerDelay + pkt->payloadDelay;
pkt->headerDelay = pkt->payloadDelay = 0;
const Tick when = curTick() + parent.delayReq(pkt) + receive_delay;
parent.masterPort.schedTimingReq(pkt, when);