2009-05-11 19:38:43 +02:00
|
|
|
/*
|
|
|
|
* Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are
|
|
|
|
* met: redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer;
|
|
|
|
* redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution;
|
|
|
|
* neither the name of the copyright holders nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived from
|
|
|
|
* this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2010-03-23 02:43:53 +01:00
|
|
|
* Unordered buffer of messages that can be inserted such
|
2009-05-11 19:38:43 +02:00
|
|
|
* that they can be dequeued after a given delta time has expired.
|
|
|
|
*/
|
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
#ifndef __MEM_RUBY_BUFFERS_MESSAGEBUFFER_HH__
|
|
|
|
#define __MEM_RUBY_BUFFERS_MESSAGEBUFFER_HH__
|
2009-05-11 19:38:43 +02:00
|
|
|
|
2010-06-11 08:17:07 +02:00
|
|
|
#include <algorithm>
|
2011-01-10 20:11:20 +01:00
|
|
|
#include <cassert>
|
2010-06-11 08:17:07 +02:00
|
|
|
#include <functional>
|
2010-03-11 03:33:11 +01:00
|
|
|
#include <iostream>
|
|
|
|
#include <string>
|
2011-04-15 19:44:06 +02:00
|
|
|
#include <vector>
|
2010-03-11 03:33:11 +01:00
|
|
|
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
#include "debug/RubyQueue.hh"
|
2011-04-15 19:44:06 +02:00
|
|
|
#include "mem/ruby/common/Address.hh"
|
2009-05-11 19:38:45 +02:00
|
|
|
#include "mem/ruby/common/Consumer.hh"
|
|
|
|
#include "mem/ruby/slicc_interface/Message.hh"
|
2014-09-01 23:55:40 +02:00
|
|
|
#include "mem/packet.hh"
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
#include "params/MessageBuffer.hh"
|
|
|
|
#include "sim/sim_object.hh"
|
2009-05-11 19:38:43 +02:00
|
|
|
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
class MessageBuffer : public SimObject
|
2010-03-23 02:43:53 +01:00
|
|
|
{
|
|
|
|
public:
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
typedef MessageBufferParams Params;
|
|
|
|
MessageBuffer(const Params *p);
|
2010-03-23 02:43:53 +01:00
|
|
|
|
2015-08-14 19:04:51 +02:00
|
|
|
void reanalyzeMessages(Addr addr);
|
2011-02-07 07:14:19 +01:00
|
|
|
void reanalyzeAllMessages();
|
2015-08-14 19:04:51 +02:00
|
|
|
void stallMessage(Addr addr);
|
2010-08-20 20:46:14 +02:00
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
// TRUE if head of queue timestamp <= SystemTime
|
2012-10-16 00:51:57 +02:00
|
|
|
bool isReady() const;
|
2010-03-23 02:43:53 +01:00
|
|
|
|
|
|
|
void
|
|
|
|
delayHead()
|
|
|
|
{
|
2015-07-04 17:43:46 +02:00
|
|
|
MsgPtr m = m_prio_heap.front();
|
2010-06-11 08:17:07 +02:00
|
|
|
std::pop_heap(m_prio_heap.begin(), m_prio_heap.end(),
|
2015-07-04 17:43:46 +02:00
|
|
|
std::greater<MsgPtr>());
|
2010-06-11 08:17:07 +02:00
|
|
|
m_prio_heap.pop_back();
|
2015-07-04 17:43:46 +02:00
|
|
|
enqueue(m, Cycles(1));
|
2010-03-23 02:43:53 +01:00
|
|
|
}
|
|
|
|
|
2014-02-21 00:26:41 +01:00
|
|
|
bool areNSlotsAvailable(unsigned int n);
|
2010-03-23 02:43:53 +01:00
|
|
|
int getPriority() { return m_priority_rank; }
|
|
|
|
void setPriority(int rank) { m_priority_rank = rank; }
|
2013-03-22 21:53:27 +01:00
|
|
|
void setConsumer(Consumer* consumer)
|
2010-03-23 02:43:53 +01:00
|
|
|
{
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
DPRINTF(RubyQueue, "Setting consumer: %s\n", *consumer);
|
2013-04-09 23:15:06 +02:00
|
|
|
if (m_consumer != NULL) {
|
|
|
|
fatal("Trying to connect %s to MessageBuffer %s. \
|
|
|
|
\n%s already connected. Check the cntrl_id's.\n",
|
|
|
|
*consumer, *this, *m_consumer);
|
|
|
|
}
|
2013-03-22 21:53:27 +01:00
|
|
|
m_consumer = consumer;
|
2010-03-23 02:43:53 +01:00
|
|
|
}
|
|
|
|
|
2013-02-11 04:43:17 +01:00
|
|
|
void setSender(ClockedObject* obj)
|
2013-01-14 17:04:21 +01:00
|
|
|
{
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
DPRINTF(RubyQueue, "Setting sender: %s\n", obj->name());
|
2013-03-22 21:53:27 +01:00
|
|
|
assert(m_sender == NULL || m_sender == obj);
|
|
|
|
m_sender = obj;
|
2013-02-11 04:43:17 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void setReceiver(ClockedObject* obj)
|
|
|
|
{
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
DPRINTF(RubyQueue, "Setting receiver: %s\n", obj->name());
|
2013-03-22 21:53:27 +01:00
|
|
|
assert(m_receiver == NULL || m_receiver == obj);
|
|
|
|
m_receiver = obj;
|
2013-01-14 17:04:21 +01:00
|
|
|
}
|
|
|
|
|
2013-03-22 21:53:27 +01:00
|
|
|
Consumer* getConsumer() { return m_consumer; }
|
2010-03-23 02:43:53 +01:00
|
|
|
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
bool getOrdered() { return m_strict_fifo; }
|
|
|
|
|
2014-02-21 00:26:41 +01:00
|
|
|
//! Function for extracting the message at the head of the
|
|
|
|
//! message queue. The function assumes that the queue is nonempty.
|
|
|
|
const Message* peek() const;
|
2010-03-23 02:43:53 +01:00
|
|
|
|
|
|
|
const MsgPtr&
|
|
|
|
peekMsgPtr() const
|
|
|
|
{
|
|
|
|
assert(isReady());
|
2015-07-04 17:43:46 +02:00
|
|
|
return m_prio_heap.front();
|
2010-03-23 02:43:53 +01:00
|
|
|
}
|
|
|
|
|
2013-02-11 04:26:24 +01:00
|
|
|
void enqueue(MsgPtr message) { enqueue(message, Cycles(1)); }
|
|
|
|
void enqueue(MsgPtr message, Cycles delta);
|
2013-01-14 17:04:21 +01:00
|
|
|
|
2014-05-23 13:07:02 +02:00
|
|
|
//! Updates the delay cycles of the message at the head of the queue,
|
2014-02-21 00:26:41 +01:00
|
|
|
//! removes it from the queue and returns its total delay.
|
2014-05-23 13:07:02 +02:00
|
|
|
Cycles dequeue();
|
2014-02-21 00:26:41 +01:00
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
void recycle();
|
|
|
|
bool isEmpty() const { return m_prio_heap.size() == 0; }
|
2015-07-20 16:15:18 +02:00
|
|
|
bool isStallMapEmpty() { return m_stall_msg_map.size() == 0; }
|
|
|
|
unsigned int getStallMapSize() { return m_stall_msg_map.size(); }
|
2010-03-23 02:43:53 +01:00
|
|
|
|
2014-03-02 06:59:57 +01:00
|
|
|
unsigned int getSize();
|
2010-03-23 02:43:53 +01:00
|
|
|
|
|
|
|
void clear();
|
|
|
|
void print(std::ostream& out) const;
|
|
|
|
void clearStats() { m_not_avail_count = 0; m_msg_counter = 0; }
|
|
|
|
|
2011-02-14 23:14:54 +01:00
|
|
|
void setIncomingLink(int link_id) { m_input_link_id = link_id; }
|
|
|
|
void setVnet(int net) { m_vnet_id = net; }
|
|
|
|
|
2015-08-19 17:02:01 +02:00
|
|
|
// Function for figuring out if any of the messages in the buffer can
|
|
|
|
// satisfy the read request for the address in the packet.
|
|
|
|
// Return value, if true, indicates that the request was fulfilled.
|
|
|
|
bool functionalRead(Packet *pkt);
|
|
|
|
|
2012-10-16 00:51:57 +02:00
|
|
|
// Function for figuring out if any of the messages in the buffer need
|
|
|
|
// to be updated with the data from the packet.
|
|
|
|
// Return value indicates the number of messages that were updated.
|
|
|
|
// This required for debugging the code.
|
|
|
|
uint32_t functionalWrite(Packet *pkt);
|
|
|
|
|
2014-02-24 02:16:15 +01:00
|
|
|
private:
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
//added by SS
|
|
|
|
const Cycles m_recycle_latency;
|
|
|
|
|
2014-02-24 02:16:15 +01:00
|
|
|
void reanalyzeList(std::list<MsgPtr> &, Tick);
|
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
private:
|
|
|
|
// Data Members (m_ prefix)
|
2013-02-11 04:43:17 +01:00
|
|
|
//! The two ends of the buffer.
|
2013-03-22 21:53:27 +01:00
|
|
|
ClockedObject* m_sender;
|
|
|
|
ClockedObject* m_receiver;
|
2013-02-11 04:43:17 +01:00
|
|
|
|
2013-01-14 17:04:21 +01:00
|
|
|
//! Consumer to signal a wakeup(), can be NULL
|
2013-03-22 21:53:27 +01:00
|
|
|
Consumer* m_consumer;
|
2015-07-04 17:43:46 +02:00
|
|
|
std::vector<MsgPtr> m_prio_heap;
|
2013-01-14 17:04:21 +01:00
|
|
|
|
2012-04-12 14:35:49 +02:00
|
|
|
// use a std::map for the stalled messages as this container is
|
|
|
|
// sorted and ensures a well-defined iteration order
|
2015-08-14 19:04:51 +02:00
|
|
|
typedef std::map<Addr, std::list<MsgPtr> > StallMsgMapType;
|
2010-08-20 20:46:14 +02:00
|
|
|
|
|
|
|
StallMsgMapType m_stall_msg_map;
|
2010-03-23 02:43:53 +01:00
|
|
|
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
const unsigned int m_max_size;
|
2013-02-11 04:26:26 +01:00
|
|
|
Cycles m_time_last_time_size_checked;
|
2013-06-24 13:57:06 +02:00
|
|
|
unsigned int m_size_last_time_size_checked;
|
2010-03-23 02:43:53 +01:00
|
|
|
|
2015-07-10 23:05:23 +02:00
|
|
|
// variables used so enqueues appear to happen immediately, while
|
2010-03-23 02:43:53 +01:00
|
|
|
// pop happen the next cycle
|
2013-02-11 04:26:26 +01:00
|
|
|
Cycles m_time_last_time_enqueue;
|
2014-03-02 06:59:58 +01:00
|
|
|
Tick m_time_last_time_pop;
|
|
|
|
Tick m_last_arrival_time;
|
|
|
|
|
2013-06-24 13:57:06 +02:00
|
|
|
unsigned int m_size_at_cycle_start;
|
|
|
|
unsigned int m_msgs_this_cycle;
|
2010-03-23 02:43:53 +01:00
|
|
|
|
|
|
|
int m_not_avail_count; // count the # of times I didn't have N
|
|
|
|
// slots available
|
2015-08-29 17:19:23 +02:00
|
|
|
uint64_t m_msg_counter;
|
2010-03-23 02:43:53 +01:00
|
|
|
int m_priority_rank;
|
ruby: Expose MessageBuffers as SimObjects
Expose MessageBuffers from SLICC controllers as SimObjects that can be
manipulated in Python. This patch has numerous benefits:
1) First and foremost, it exposes MessageBuffers as SimObjects that can be
manipulated in Python code. This allows parameters to be set and checked in
Python code to avoid obfuscating parameters within protocol files. Further, now
as SimObjects, MessageBuffer parameters are printed to config output files as a
way to track parameters across simulations (e.g. buffer sizes)
2) Cleans up special-case code for responseFromMemory buffers, and aligns their
instantiation and use with mandatoryQueue buffers. These two special buffers
are the only MessageBuffers that are exposed to components outside of SLICC
controllers, and they're both slave ends of these buffers. They should be
exposed outside of SLICC in the same way, and this patch does it.
3) Distinguishes buffer-specific parameters from buffer-to-network parameters.
Specifically, buffer size, randomization, ordering, recycle latency, and ports
are all specific to a MessageBuffer, while the virtual network ID and type are
intrinsics of how the buffer is connected to network ports. The former are
specified in the Python object, while the latter are specified in the
controller *.sm files. Unlike buffer-specific parameters, which may need to
change depending on the simulated system structure, buffer-to-network
parameters can be specified statically for most or all different simulated
systems.
2015-08-14 07:19:44 +02:00
|
|
|
const bool m_strict_fifo;
|
|
|
|
const bool m_randomization;
|
2013-02-11 04:26:24 +01:00
|
|
|
|
2011-02-14 23:14:54 +01:00
|
|
|
int m_input_link_id;
|
|
|
|
int m_vnet_id;
|
2009-05-11 19:38:43 +02:00
|
|
|
};
|
|
|
|
|
2013-02-19 11:56:07 +01:00
|
|
|
Cycles random_time();
|
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
inline std::ostream&
|
|
|
|
operator<<(std::ostream& out, const MessageBuffer& obj)
|
2009-05-11 19:38:43 +02:00
|
|
|
{
|
2010-03-23 02:43:53 +01:00
|
|
|
obj.print(out);
|
|
|
|
out << std::flush;
|
|
|
|
return out;
|
2009-05-11 19:38:43 +02:00
|
|
|
}
|
|
|
|
|
2010-03-23 02:43:53 +01:00
|
|
|
#endif // __MEM_RUBY_BUFFERS_MESSAGEBUFFER_HH__
|