gem5 abstractMemory simpleMemory

        粗略的把gem5 documentation扫了一遍。仍不知道如何建立一个以PCM位介质的内存模型。于是又google了一段时间，在gem5 users 的mailing list中找到了点有用的东西how and where to start gem5。于是按照他的建议，看了下源码src/mem/Abstrac_memory.*   src/mem/simple_mem.*。似乎有了点理解。

        先来看看 AbstractMemory.py

class AbstractMemory(MemObject):    type = 'AbstractMemory'    abstract = True    cxx_header = "mem/abstract_mem.hh"    # A default memory size of 128 MB (starting at 0) is used to    # simplify the regressions    range = Param.AddrRange('128MB', "Address range (potentially interleaved)")    null = Param.Bool(False, "Do not store data, always return zero")    # All memories are passed to the global physical memory, and    # certain memories may be excluded from the global address map,    # e.g. by the testers that use shadow memories as a reference    in_addr_map = Param.Bool(True, "Memory part of the global address map")    # Should the bootloader include this memory when passing    # configuration information about the physical memory layout to    # the kernel, e.g. using ATAG or ACPI    conf_table_reported = Param.Bool(True, "Report to configuration table")

       首先既然是内存类，既然要继承MemObject。而MemObject最重要的地方在于定义了两个方法用来获取master port 和 slave port 。而关于master port和slave port 在gem5中的第一篇tutorial中有介绍。这里截出个人认为比较重要的两句话：1.A master module has at least one master port, a slave module at least one slave port, and an interconnect module at least one of each  2.A master module, e.g. a CPU, changes the state of a slave module,e.g. a memory through a Request transported between master ports and slave ports using Packets。也就是说master port往往是在master module上的，而master module往往是用来改变slave module的状态的。比如由CPU发出的request packet t改变了memory的状态。对了，GEM5中CPU和memory的交互往往是建立在packet上的。

       然后再看该AbstractMemory定义了几个跟memory相关的属性。其中null变量是指该块内存存不了数据，你非要从上面取数据的话，只能得到0。而conf_table_reported变量是用来告诉bootloader是否要把该块内存的存在告诉内核。不告诉的话，那内核就不知道该块内核的存在。我觉得是应该配合in_addr_map变量的使用。如果in_addr_map=false的话，那么该块内存应该就不能用于全局地址映射。

好了，再来看看Abstract_mem.h：

/** * Locked address class that represents a physical address and a * context id. */class LockedAddr {  private:    // on alpha, minimum LL/SC granularity is 16 bytes, so lower    // bits need to masked off.    static const Addr Addr_Mask = 0xf;  public:    // locked address    Addr addr;    // locking hw context    const ContextID contextId;    static Addr mask(Addr paddr) { return (paddr & ~Addr_Mask); }    // check for matching execution context    bool matchesContext(Request *req) const    {        return (contextId == req->contextId());    }    LockedAddr(Request *req) : addr(mask(req->getPaddr())),                               contextId(req->contextId())    {}    // constructor for unserialization use    LockedAddr(Addr _addr, int _cid) : addr(_addr), contextId(_cid)    {}};

    首先是LockedAddr类，刚开始看到这个类的时候，我也不知道这个变量是用来干嘛的。后来google了一下，这个东西跟Load-link/store-conditional有关。具体来说应该算是一个同步操作原语，从某种意义上来说与compare and sawp 等价。就是比如说我要修改某一地址上存储的值。我先“锁”住这块地址（这里锁不是真的锁，只是相当于标记一下），然后存新值得时候，当且仅当该地址上没有发生更新操作时，才存新值。否则，存新值操作失败。也就是分两步，第一步是load-link，第二步是store-conditional。而store不一定成功。据说它比compare and swap的厉害之处在于，即使在被标记的地址上发生的更新操作跟原值一样。也会导致store操作失败。具体可看wiki啦。然后这个类就声明了跟这个同步操作原语相关的Addr类。

    然后是AbstractMemory类，这个类挑几个重点说说。首先它作为一个Memory类，提供了它应当提供的reading和writing 这块Memory的方法。但是没有提供任何计时信息。当然它代表的是一块的连续内存啦。其中uint8_t* pmemAddr;变量是用来LMemory之所以叫Memory，就是因为它是用来放数据的，虽然是个模拟程序，为了模拟的像，总得从主机上找个地方放数据吧。嗯，该指针指向的就是主机上放该块Memory数据的地方。std::list<LockedAddr> lockedAddrList;这个变量跟上文提到的Load-link/store-conditional有关。凡是被load-link标记过的地址就会加入到这个链表中。自然这两个函数 bool checkLockedAddrList(PacketPtr pkt);，  void trackLoadLocked(PacketPtr pkt);也是为了用来标记和检查packet上addr的load-link的状态的。

 bool writeOK(PacketPtr pkt) {        Request *req = pkt->req;        if (lockedAddrList.empty()) {            // no locked addrs: nothing to check, store_conditional fails            bool isLLSC = pkt->isLLSC();            if (isLLSC) {                req->setExtraData(0);            }            return !isLLSC; // only do write if not an sc        } else {            // iterate over list...            return checkLockedAddrList(pkt);        }    }

     上面这段代码就比较厉害啦。首先pkt里面是个写请求，它是想看看该次写请求能不能写成功。嗯，它先检查了下lockedAddrList是否为空，如果该链表为空的话，要么表示没有Addr进行了store之前的load-link操作，要么表示有Addr进行了load-link操作，但是被之前的store操作清空了，或者表示该内存根本就不支持LL/SC(load-link/store-conditional)。这么一说。下面的逻辑就清楚了。而如果链表为非空的话，自然要扫一遍链表啦。如果有匹配的，就可以store啦。关于checkLockAddrList操作请继续往下看。

/** Number of total bytes read from this memory */    Stats::Vector bytesRead;    /** Number of instruction bytes read from this memory */    Stats::Vector bytesInstRead;    /** Number of bytes written to this memory */    Stats::Vector bytesWritten;    /** Number of read requests */    Stats::Vector numReads;    /** Number of write requests */    Stats::Vector numWrites;    /** Number of other requests */    Stats::Vector numOther;    /** Read bandwidth from this memory */    Stats::Formula bwRead;    /** Read bandwidth from this memory */    Stats::Formula bwInstRead;    /** Write bandwidth from this memory */    Stats::Formula bwWrite;    /** Total bandwidth from this memory */    Stats::Formula bwTotal;

       然后是一些stats相关的变量。这没什么好说的啦。注释说的挺清楚的。不过我也没搞懂为什么要用Vector来存，以后看了别的代码回来再理解试试吧。

       再来看看Abstrac_mem.c文件吧：

voidAbstractMemory::trackLoadLocked(PacketPtr pkt){    Request *req = pkt->req;    Addr paddr = LockedAddr::mask(req->getPaddr());    // first we check if we already have a locked addr for this    // xc.  Since each xc only gets one, we just update the    // existing record with the new address.    list<LockedAddr>::iterator i;    for (i = lockedAddrList.begin(); i != lockedAddrList.end(); ++i) {        if (i->matchesContext(req)) {            DPRINTF(LLSC, "Modifying lock record: context %d addr %#x\n",                    req->contextId(), paddr);            i->addr = paddr;            return;        }    }    // no record for this xc: need to allocate a new one    DPRINTF(LLSC, "Adding lock record: context %d addr %#x\n",            req->contextId(), paddr);    lockedAddrList.push_front(LockedAddr(req));}

         这就是上文提到的trackLoadLocked的实现。就是LL/SC中的LL操作。如果之前有匹配contextid的LockAddr在链表中。那么只需要把旧地址改成新地址就可以了。我也不知道xc是什么啊（其实我对xc还挺有好感的）。然后如果不匹配的话，自然要给链表新加一项啦。然后是checkLockedAddrList方法。gem5自带代码注释真的好充分啊。我觉得我就是个翻译啊。只要是写操作就要调用这个函数，无论是普通的store还是store-conditional。因为是写的话，就要把被“动”过的地址从lockedAddrList链表中移出去啊。因为被“动”过了，所以以后的store-conditional肯定是fail啊。然后对于store-conditional操作，一定要是在lockedAddrList链表中才能返回successful。然后不要还要移除链表中地址相同而contexteid不同的LockAddr因为该块地址被“动”过了。

        再就是void AbstractMemory::access(PacketPtr pkt)方法。这是真正的对Memory访问的实现。如果pkt中要求的地址已经由Cache处理过了，那么直接返回。如果还未处理。那么分以下三种情形：swap,read,write。其中swap是指把包中存的值，于包指定的地址（在memory中）上的值进行交换。然后就是普通的read和write操作了。当然进行相关操作的时候，要更新stats信息。对了，还有一个invalidate操作是write-invalidate操作，什么都不做，因为其本来就是什么都不做（对于memory来说，主要是在cache层才有事做，我也是猜的。应该跟snoop protocol有关）。 invalidate is WriteInvalidate。所以在write前面，为了保证一致性。而functionalAccess方法就是做事情，但是不参与stats。暂时就写这么多吧。我也不知道怎么填坑。。。

---------------------------------------------------------------我是分割线-----------------------------------------------------------------------------------------------------------------------------------------------------

       再来看看SimpleMemory.py。它继承自AbstractMemory。并且加入了延迟和不确定延迟变量（latence_var），并且加入了带宽限制，保证数据的传输速度不超过带宽。原来这里的带宽也是指传输速率啊。我以为是指每次的传输位宽呢刚开始。

         然后是simple_mem.h。这里说到了simple_memory是只有一个port的内存控制器。 在该文件中还定义了 类：

class DeferredPacket{      public:        const Tick tick;        const PacketPtr pkt;        DeferredPacket(PacketPtr _pkt, Tick _tick) : tick(_tick), pkt(_pkt)        { }    };

       该类是用于recvTimingReq函数的。根据tutorial中介绍说：For a slave module, typically schedule an action to send a response at a later time。也就是说对于recvTimingReq，该memory会过一会在发送response。而tick就是用来记录未来发送的时刻的。然后专门定义了std::list<DeferredPacket> packetQueue链表用来存储过会发的DeferredPacket。再就是retryReq bool型变量用来标记是否需要告诉master重新发送请求，因为该请求发送的时候，内存忙，无法接收。而release函数就是在内存忙完后，把自身标记为不忙，如果有retryReq标记起告诉master重发请求的作用的。

         最后来看看simple_mem.c文件。好吧，我承认我写的不走心。因为我自己也不是太理解。来看这个函数：

TickSimpleMemory::recvAtomic(PacketPtr pkt){    access(pkt);    return pkt->cacheResponding() ? 0 : getLatency();}

          跟tutorial中描述的一样，首先去执行pkt中要求的操作，即access(pkt)。然后如果cache未命中的话，返回自己本身的延迟。并没有推迟发送response的坏习惯（For a slave module, perform any state updates and turn the request into a
response）。然后是这个函数：

voidSimpleMemory::recvFunctional(PacketPtr pkt){    pkt->pushLabel(name());    functionalAccess(pkt);    bool done = false;    auto p = packetQueue.begin();    // potentially update the packets in our packet queue as well    while (!done && p != packetQueue.end()) {        done = pkt->checkFunctional(p->pkt);        ++p;    }    pkt->popLabel();}

诚如tutorial中说的一样，它除了不参与stats，还检查了一遍packetQueen。（Typically check internal (packet) buffers against request packet）暂时并不知道检查带来了什么影响。

       然后是这个recvTimingReq。首先，该方法会检查自己是不是忙，如果memory控制器在忙的状态会把retryReq标记为true。然后返回false。都忙了，自然无法处理pkt啊，所以返回false。在这之前，如果它检查发现retryReq为true。就直接返回false，意思是我都让你待会再发了，你又发。对不起，不接收。

 if (pkt->isRead() || pkt->isWrite()) {        // calculate an appropriate tick to release to not exceed        // the bandwidth limit        Tick duration = pkt->getSize() * bandwidth;        // only consider ourselves busy if there is any need to wait        // to avoid extra events being scheduled for (infinitely) fast        // memories        if (duration != 0) {            schedule(releaseEvent, curTick() + duration);            isBusy = true;        }    }

      而上面这段代码，实现了对延迟的模拟。并且在这段时期内，把memory控制器标记为忙。

      然后经过recvAtomic(pkt);完成pkt的要求，并且如果需要response的话，开始make response,并把response和对应的发送时间加入packetQueen队列。

     暂时只能理解这么多了。。