* ========== Copyright Header Begin ==========================================
* OpenSPARC T2 Processor File: MemorySync.h
* Copyright (c) 2006 Sun Microsystems, Inc. All Rights Reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES.
* The above named program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public
* License version 2 as published by the Free Software Foundation.
* The above named program is distributed in the hope that it will be
* useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
* You should have received a copy of the GNU General Public
* License along with this work; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
* ========== Copyright Header End ============================================
/************************************************************************
** Copyright (C) 2002, Sun Microsystems, Inc.
** Sun considers its source code as an unpublished, proprietary
** trade secret and it is available only under strict license provisions.
** This copyright notice is placed here only to protect Sun in the event
** the source is deemed a published work. Disassembly, decompilation,
** or other means of reducing the object code to human readable form
** is prohibited by the license agreement under which this code is
** provided to the user or company in possession of this copy."
*************************************************************************/
#include "MemoryTransaction.h"
#include "MemorySyncDefs.h"
#include "LoadStoreCmd.h"
#include "MemoryAccessBuffer.h"
#include "LoadStoreBuffer.h"
#include "RieslingInterface.h"
#include "MemorySyncMessage.h"
#include "SS_PliSocket.h"
* MemorySync class extends Riesling's memory to provide Riesling same
* memory images as RTL-TestBench
* When RTL and Riesling perform lock-step simulation, RTL and Riesling
* may see different data, especially for multi-thread microprocessors.
* For example, considering the following STEP execution sequence
* <LI> (1) TO stores to address A (where T0 means thread 0)
* <LI> (2) TO reads address A
* <LI> (3) T1 reads address A (where T1 means thread 1)
* Assume all load/store are are normal load/store, and not to IO address
* space. Then, it is pretty sure that instruction (2) will read data
* written by (1). However, this is not necessary true for (3). If the store
* data is still in the store buffer of thread 0, then instruction (3) will
* not see this data. Without any other help, Riesling will always read
* data written by (1), which is wrong in this scenario.
* Suppose in the above sequence the T0 and T1 are replaced with C0 (core 0)
* (Assume every core has its own D$)
* <LI> (1) CO stores to address A
* <LI> (2) CO reads address A
* <LI> (3) C1 reads address A
* Similarly, it cannot tell which data (3) will get based on just the sequence.
* Riesling, without any help, will agian always get data from (1). However,
* it is possible (3) gets data from its own D$ which still contains data
* before (1). (The execution of (1) will send an invalidation to core 1,
* but it may not yet reach to core 1's D$ before (3) is executed.)
* This MemorySync model is designed to provide Riesling the same memory image
* as the RTL. To do so, three things are needed
* - data structures to maintain transient data,
* - mechanism to map STEP (instruction execution by Riesling) to right data,
* - APIs to RTL to guide data flow
* Riesling can see this consistent memory view by not accessing memory directly,
* instead it should access memory through this model.
* This module models 4 essential data structures: fetch buffer, load buffer,
* store buffer, and memory access buffer. The fetch buffer, load buffer, and
* and store buffer are created for each thread; while the memory access buffer
* is shared among all threads.
* The memory access buffer (MAB) maintains the global data access order, as
* well as the memory image at the moment the related command is issued. The
* memory images maintained include per core L1$ content and global L2$ and
* Memory content. The L2$ and physical memory images are considered the same
* because (1) the model assumes L2$ is the first memory component shared by
* all of the cores, and (2) a write committed to L2$ is observable immediately
* The first condition indicates that all (cacheable) accesses have to access
* L2$ first, which guarantees consistency between L2 and memory. (Strictly
* speaking, we should also assume that cacheable data cannot be changed to
* non-cacheable data to avoid different image between L2 and memory.)
* The second condition indicates a read from L2$ after a write to L2$ must
* get the data written by the previous write. This is to guarantee there
* exists only one L2 image. If any of these conditions is violated, then
* the model may need to be revised.
* Data is stored in the <data> field of an MAB entry, and the type indicates
* which image it maintains. The StoreCommit entry contains data for L2/Memory,
* the LoadFill/StoreUpdate entry contains data for the D$, and the FetchFill
* type contains data for the I$. L1$ image needs to be presented as unit of
* a cache line. Therefore, each LoadFill/FetchFill command create multiple
* entries in the MAB since the data size of a MAB entry is limited to 8 bytes.
* L2$ image does not have this need since it is actually the same as memory.
* If an access supposed to get data from StoreCommit entry and cannot find
* any match in the MAB, then it can just get data from the (Riesling) memory.
* The fetch buffer has an entry associated with every intruction fetch. The
* order of these entries is the same as the instruction fetch order. A link
* pointing to the corresponding FetchData in MAB is set when the FetchData
* command is received and executed.
* When an instruction is about to be executed, Riesling calls MemorySync::
* postMemoryAccess() in order to obtain the instruction word. This callback
* method maps the instruction with one of the entries in the fetch buffer.
* Then, via the link of that entry, the method gets the instruction word
* from the FetchData in the MAB, and assigns that back to the Riesling.
* In matching the instruction with the fetch buffer entry, the model makes
* the assumption that intructions are executed in the same order as the
* instruction fetch. However, the model allows speculative fetches. Hence,
* the matching is done by looking at the oldest, non-executed, and same PC
* entry in the fetch buffer. All non-executed FetchIssue entries before this
* matched one are considered as speculative fetch operations, and are thus
* Similar to the fetch buffer, the load buffer has an entry associated with
* every load instruction. But, unlike the fetch buffer, entries in the load
* buffer must have a one-to-one mapping with load instructions. In addition,
* the order in the load buffer must be in the program order as the LoadIssue
* commands are required to be sent in the program order. Also similar to the
* fetch buffer entry, a link pointing to the corresponding LoadData is set
* when the LoadData command is received and executed.
* When a load is executed, Riesling again calls MemorySync::postMemoryAccess()
* to obtain its load data. This callback method maps the instruction with one
* of the entries in the load buffer. Then, via the link of that entry, it gets
* the data from the LoadData in the MAB, and assigns that back to the Riesling.
* In matching the instruction with the fetch buffer entry, the model makes the
* assumption that the Riesling is requested (by the RTL) to execute the load
* instructions in the program order, except for I/O access, which is allowed
* to be executed out-of-order relative to other loads. As a result, the method
* maps the load instruction to the first non-executed entry in the load buffer
* unless it is an I/O access, in which address is also considered.
* Note that the condition that requires load instruction be executed in program
* order in Riesling can be relaxed to the condition that requires only loads
* accessing to the same 8-byte block be executed in the program order with minor
* program modification. (Refer to the algorithm that matches the LoadData with
* LoadIssue in MemorySync::handleLoadData().)
* The store buffer also has an entry associated with every store. Difference
* from fetch buffer and load buffer entry is that the store buffer entry also
* has <data> field and a <byte_mask> indicating which byte is valid. When a
* StoreCommit command is received by the module, it merges the data of the
* matched store buffer entry with the current L2/Memory image of that 8-byte
* block. The merged data is then saved in the StoreCommit entry in the MAB.
* When a store is executed, Riesling calls MemorySync::preMemoryAccess(),
* and pass the data to be written by it. The method compares the data with
* the data in the model's store buffer, which represents RTL's data, and
* reports error if happens.
* The assumption made to map the store to the store buffer entry is that
* the stores are executed in program order. So, the match simply to find
* the first non-executed StoreIssue entry.
* To simplify design and to handle some special cases, the store buffer is
* actually modeled by three differnt data structures: stb_, rmoStb_ (rmo
* store buffer), and retStb_ (retired store buffer). All StoreIssue commands
* first create entries in the stb_. Upon receiving its StoreAck command, the
* entry is moved to either rmoStb_ (if RMO stores) or retStb_ (otherwise).
* As a result, the stb_ is suppose to contain the same store instructions as
* RTL's store buffer so that the store buffer bypassing search can just search
* the stb_. However, in some case, such as the current Niagara 1 set-up, due
* to the difficulty to get the exact time, the RTL may still allows bypassing
* even after its StoreAck is issued. To tolerate such situation, normal stores
* are moved to retStb_ on StoreAck. Store buffer bypassing search then also
* searches this buffer if none is found matched in the stb_.
* The rmoStb_ is introduced to solve another issue. By definition, RMO stores
* are not required to perform dependence check, and are only required to obey
* the RMO memory consistency protocol. Hence, a RMO store can be issued (from
* store buffer) to L2 without waiting for the commit of a prior store. It is
* removed from the store buffer when it is issued. Therefore, its StoreAck is
* sent before StoreCommit; while normal stores have StoreAck after StoreCommit.
* The rmoStb_ is designed to hold the RMO StoreIssue entries when they are
* removed from stb_ so that the instruction-data mapping is possible.
* RMO Stores include block stores and stores using *_BLOCK_INIT_ST_QUAD_LDD_*.
* Except for the assumptions describe above, the model also has some other
* assumption due to the implementation and testbench issue. This paragraph
* summarizes all assumptions here:
* <LI> L2$ is the first memory component shared by all cores
* <LI> a write committed to L2$ is observable immediately by all of the cores.
* <LI> cacheable data cannot be changed to noncacheable data during the test
* <LI> intructions are executed in the same order as the instruction fetch
* (but allows speculative fetches)
* <LI> load instructions are executed in the program order, except for I/O
* <LI> store instructions are executed in the program order
* <LI> LoadData to the same 8-byte block is in the program order
* <LI> StoreCommit to the same 8-byte block is in the program order
* <LI> no STB bypassing of the rmo store data is possible
* The design attempts to be microarchitecture-independent. The microarchitecture
* dependent part is parameterized. These microarchitecture dependent parameters
* are either defined in MemorySyncDefs.h or passed as arguments when creating
* the MemorySync object. These parameters include:
* - system type (N1, N2, ...)
* - number of cores per chip,
* - number of threads per core,
* @see MemoryAccessBuffer.h
static MemorySync
* msyncObj
;
static std::string
dumpBuffers();
MemorySync(int max_strands
, int strands_per_core
, int cores_per_cpu
, int memDebug
, int tsoChecker
=1, int callback
=1);
* @param orig The MemorySync object to copy.
MemorySync( const MemorySync
&orig
);
* @param rhs The right hand side of the equality operator
* @return Return true if this objec and rhs are equal,
bool operator==( const MemorySync
&rhs
) const;
* @param rhs The right hand side of the assignment operator.
* @return The lvalue of the assignment.
const MemorySync
& operator=( const MemorySync
&rhs
);
* Return a string representation of this MemorySync object.
std::string
toString() const;
* return a pointer to the (global) memory access buffer
MemoryAccessBuffer
* getMABPtr () { return &mab_
; } * return a pointer to a specified strand's (thread's) load buffer
* @return pointer to the load buffer of the specified thread, ldb_[tid]
LoadStoreBuffer
* getLDBPtr (int tid
) { return &ldb_
[tid
]; }; * return a pointer to a specified thread's store buffer
* @return pointer to the store buffer of specified tread, stb_[tid]
LoadStoreBuffer
* getSTBPtr (int tid
) { return &stb_
[tid
]; }; * return a pointer to a specified thread's store buffer
* @return pointer to the store buffer of specified tread, stb_[tid]
LoadStoreBuffer
* getRSTBPtr (int tid
) { return &retStb_
[tid
]; } * assign data to StoreIssue entry
* @param data data to be written
* @param rmo indicates if this is for a rmo store
void setTestBenchData(uint32_t tid
, uint64_t addr
, uint64_t data
, bool rmo
);
* remove a StoreIssue entry from the specified thread's retired store buffer
void removeRetiredStore (uint64_t addr
, uint32_t tid
);
* Executes LoadIssue MemorySync API command
* Depending on the instruction type, this method pushes 1-8 entries into the
* load buffer of that thread: <br>
* - Block-Load, which accesses 64 bytes, results in 8 entries; <br>
* - Quad-Load, which accesses 16 bytes, results in 2 entries; <br>
* - normal load, which accesses 1-8 bytes, results in 1 entry.
* In N2, this method has to figure out whether the data source is store buffer
* or not. If it is, then the result will be used for LoadData sent later.
* @param cmd a LoadStoreCmd object reference that contains the info of the LoadIssue
void handleLoadIssue(LoadStoreCmd
& cmd
);
* Executes LoadData MemorySync API command
* Depending on the instruction type, this method pushes 1 or 2 (only for N2 so far)
* entries into the global memory access buffer. In addition, it accesses data for
* each entry according to the data source specified in the command. Note that the
* MemorySync model for N2 actually has to figure out if the data source is store
* buffer or not by itself.
* If the data source is store buffer, then data should get from the store buffer
* If the data source is L1, then data comes from LoadFill/StoreUpdate of the MAB,
* or, if not found, from Riesling memory <br>
* If the data source is L2/Memory, then data comes from StoreCommit of the MAB,
* or, if not found, from Riesling memory <br>
* @param cmd a LoadStoreCmd object reference that contains the info of the LoadData
void handleLoadData(LoadStoreCmd
& cmd
);
* Executes LoadFill MemorySync API command
* This method pushes DCACHE_LINE_SIZE/8 entries into the global memory access buffer.
* Each entry is filled with data at the moment the corresponding LoadData is issued.
* Note that while searching for the matched LoadData entry, the matched one should
* also have cacheL1 set. However, N2 does not specify cacheL1 flag in its LoadData
* command. It requires the MemorySync model follow the assumption that every thread
* can have only one outstanding load, i.e., the LoadData that results in the LoadFill
* must be the only non-executed LoadData entry of that thread.
* @param cmd a LoadStoreCmd object reference that contains the info of the LoadFill
void handleLoadFill(LoadStoreCmd
& cmd
);
* Executes StoreIssue MemorySync API command
* This method pushes one entry for each of this command into its store buffer.
* Although <data> is expected, some environment may not have data ready when
* this command is issued. In this case, another method setTestBenchData() can
* be used to set the data in the store buffer.
* @param cmd a LoadStoreCmd object reference that contains the info of the StoreIssue
void handleStoreIssue(LoadStoreCmd
& cmd
);
* Executes StoreCommit MemorySync API command
* This method merges the corresponding StoreIssue data with the L2/momory data
* at the time when the StoreCommit is issued. The merged data is stored in the
* StoreCommit entry in the MAB, which represents the L2/Memory image at that
* time. Usually, a StoreCommit has one matched entry in the store buffer and
* results in one entry in MAB. One exception of this is the BLK_INIT store.
* If satisfying certain conditions, a BLK_INIT store can zero a L2 cache line.
* In this case, the model inserts L2CACHE_LINE_SIZE/8 entries into MAB with 0
* in their <data> fields, except for the one that has data written by this
* @param cmd a LoadStoreCmd object reference that contains the info of the StoreCommit
void handleStoreCommit (LoadStoreCmd
& cmd
) ;
* Executes StoreAck MemorySync API command
* This method move the matched StoreIssue in the stb_ into either retStb_ (for
* normal stores) or rmoStb_ (for RMO stores).
* @param cmd a LoadStoreCmd object reference that contains the info of the StoreAck
void handleStoreAck (LoadStoreCmd
& cmd
);
* Executes StoreInv MemorySync API command
* This method notifies the StoreCommit that cuases the StoreInv that a StoreInv
* The function of StoreInv command is to prevent the StoreCommit that initiates
* the StoreInv from retiring from the Memory Aceess Buffer (MAB) too early. A
* StoreCommit cannot be removed from the MAB until it reaches to the head of the
* MAB and all corresponding StoreInv and StoreUpdate are done. If the latter
* condition is violate, then correct data may not be obtained. Considering the
* - C0T0 StoreCommit A, inv=8'b00000010
* - C0T1 LoadData A (L1 hit)
* If the first StoreCommit is retired from the MAB without waiting for the
* StoreInv completes, then since the MAB StoreCommit retirement also results in
* writing its data to the Riesling memory, the LoadData would read StoreCommit's
* data, which is wrong. The LoadData should get data before the StoreCommit.
* The implementation also creates an entry for the StoreInv in the MAB after it
* notifies the StoreCommit it is done. This is actually not necessary, doing so
* allows us examine the command sequence in MAB, which helps debug.
* @param cmd a LoadStoreCmd object reference that contains the info of the StoreInv
void handleStoreInv (LoadStoreCmd
& cmd
);
* Executes StoreUpdate MemorySync API command
* This method notifies the StoreCommit that cuases the StoreUpdate that a
* StoreUpdate is performed. In addition, it also creates a StoreUpdate
* entry in the MAB, and copy the data in the StoreCommit to the <data> field
* of the StoreUpdate. Recall that the StoreUpdate keeps the D$ data image.
* The other function of StoreUpdate command is the same as StoreInv, that is
* is to prevent the StoreCommit that initiates the StoreUpdate from retiring
* from the Memory Aceess Buffer (MAB) too early. Reference the example in the
* handleStoreInv() for more details.
* @param cmd a LoadStoreCmd object reference that contains the info of the StoreUpdate
void handleStoreUpdate (LoadStoreCmd
& cmd
);
* Executes Evict MemorySync API command
* This method creates DCACHE_LINE_SIZE/8 Evict entries in the MAB to indicate
* a L2 cache line is evicted. Each D$ line needs to have one Evict since its
* <inv> may be different.
* The function of Evict and EvictInv is to mimic L2 cache line eviction. Let's
* use an example to explain the necessity of implementing them. Considering the
* same sequence used in handleStoreInv():
* - C0T0 StoreCommit A, inv=8'b00000010
* - C0T1 LoadData A (L1 hit)
* From the value of <inv>, we know that the same line exists in core1's L1.
* Suppose that before the StoreCommit, the line in L2 is evicted. Then, the
* the StoreCommit would have <inv>=8'b00000000. Consequently, similar error will
* happen: StoreCommit is removed too early so that the LoadData (L1 hit) gets
* wrong data. Evict and EvictInv can solve this problem. Including these two
* command, the above situation will have the following sequence:
* - Evict A, inv=8'b00000010
* - C0T0 StoreCommit A, inv=8'b00000010
* - C0T1 LoadData A (L1 hit)
* Again, EvictInv prevents Evict from being removed too early.
* The implementation also creates an entry for the EvictInv in the MAB after it
* notifies the StoreCommit it is done. This is actually not necessary, doing so
* allows us examine the command sequence in MAB, which helps debug.
* @param cmd a LoadStoreCmd object reference that contains the info of the Evict
void handleEvict (LoadStoreCmd
& cmd
);
* Executes EvictInv MemorySync API command
* This method creates L2CACHE_LINE_SIZE/8 EvictInv entries in the MAB, and
* notifies the corresponding Evict entries in the MAB that the EvictInv is
* performed. Reference to handleEvict() for more discussion.
* @param cmd a LoadStoreCmd object reference that contains the info of the EvictInv
void handleEvictInv (LoadStoreCmd
& cmd
);
* To allow DMA accesses from I/O. It occurres when a SIU Store (from ENET
* or PCI) is seen in the L2 or when Bench back-door stores to memory.
* Riesling will update memory immediately when MemorySlam message is
* No SSTEP will be sent with this message.
* No checking is performed by Reisling on this message.
* No checking against any load/store in-flight.
void handleStoreSlam(StoreIssueCmd
& cmd
);
* DMA_STORE, similar to MEM_SLAM, but allow inv_vec to handle conflict
void handleDmaStoreStart(LoadStoreCmd
& cmd
);
void handleDmaStore (LoadStoreCmd
& cmd
) ;
void handleFetchIssue(LoadStoreCmd
& cmd
);
void handleFetchData(LoadStoreCmd
& cmd
);
void handleFetchFill(LoadStoreCmd
& cmd
);
void preMemoryAccess( MemoryTransaction
&xact
);
void postMemoryAccess( MemoryTransaction
& xact
);
static void pre_memory_access( void* msync
, MemoryTransaction
& xact
);
static void post_memory_access( void* msync
, MemoryTransaction
& xact
);
uint64_t getL1Instr(LoadStoreCmd
& cmd
);
uint64_t getL1Data(LoadStoreCmd
& cmd
);
uint64_t getL2Data(std::list
<MemoryAccessEntry
>::iterator from
, LoadStoreCmd
& cmd
);
uint64_t align2addr (uint64_t data
, uint8_t size
, uint32_t addr_offset
);
uint64_t align8byte (uint64_t data
, uint8_t size
, uint32_t addr_offset
);
uint64_t merge (uint64_t todata
, uint64_t fromdata
, uint8_t fromszv
);
void bufWriteMemory (std::vector
<MemoryAccessEntry
>& wdbuf
);
uint64_t byteMask(const uint8_t vbyte
);
uint64_t iSeq (uint32_t tid
) { return (iseq_
[tid
]++); }
uint64_t getIseq (uint32_t tid
) { return iseq_
[tid
]; }
Tso::TsoChecker
* getTsoCheckerPtr () { return tsoChecker_
; }
* turn off msync model related callbacks
void nullMsyncCallback();
* empty the buffers of a specified strand-id
void flushMsyncCallback(int tid
);
* if LoadPop, pop and discard the Load at the top of your queue.
* You will have received a LDISSUE and LDDATA for this Load before
* It is not possible for bench to send the <pa> on LDPOP.
* So, Riesling can't check that correct Load is popped.
* However, if wrong Load is discarded, the next Load will likely fail.
void handleLoadPop(int tid
);
* if StorePop, pop and discard the Store at the top of your queue.
* You will have received a STISSUE for this Store before
void handleStorePop(int tid
);
* compare a N-byte data block in memory with the data provided by
* testbench, throw error if miscompare.
void handleMemoryCheck(uint64_t paddr
, uint64_t* data
, int dataSize
);
* flush out all entries, invoked when encounter INTP=0 system-wide
* a hook for address translation. For example, dma_loopback that
* translates a I/O address to RAM address.
typedef uint64_t (* AddrTransCB
)(uint64_t);
void setAddrTransCB(AddrTransCB cb
) { addrTrans
= cb
; }
// handle sniper related load/store
void handleSniper(int tid
, uint64_t addr
, INSTR_TYPE itype
, uint64_t data
);
void setCoreEnable(int node_index
, uint64_t data
);
// socket file descriptor to RTL testbench, used to report error
void completeStoreInvStoreUpdate (LoadStoreCmd
& cmd
);
MemoryAccessBuffer mab_
; // global memory access buffer LoadStoreBuffer
* ldb_
; // load buffer LoadStoreBuffer
* stb_
; // store buffer LoadStoreBuffer
* retStb_
; LoadStoreBuffer
* rmoStb_
; LoadStoreBuffer
* ifb_
; // I-Fetch Buffer uint64_t* iseq_
; // load/store instruction sequence number
/* The following buffer, retStb_, is introduced to store entries removed
from the stb_ whose data may be need for the following load. This is to
solve the Ni signal's timing issue. May not need for N2. */
/* LoadStoreBuffer retStb_[MAX_STRANDS]; */
/* This buffer is for storing RMO-store instructions. In N2, this type of
stores leaves STB when it is issued to L2, hence StoreAck will be before
StoreL2Commit. In addition, they may have out-of-order invalidation
/* LoadStoreBuffer rmoStb_[MAX_STRANDS]; */
Tso::TsoChecker
* tsoChecker_
;
// hook to provide optional (I/O) address translation
// inv_vec mask, 1 bit per core,
// inv_vec in st_commit is arranged from left to right as: core_n_1
// core_n_2 ... core_1 core_0.
// inv_vec_mask is arranged differently, inv_vec_mask[0] keeps core_7 ...
// core_0, from left to right. inv_vec_mask[1] keeps core_15 ... core_8,
// from left to right, and so on.
uint8_t inv_vec_mask
[INV_VEC_SIZE
];
#endif /* _MEMORYMODEL_H */
projects / OpenSPARC-T2-SAM / blob