This is a simple version of an Abstract Bus Model. This version isdeveloped using SystemC 2.0, and is verified on all platforms supportedby SystemC 2.0.By Ric Hilderink, Synopsys, Inc., 11 Oct 2001.Updated by Martin Janssen, Synopsys, Inc., 27 Nov 2001.Updated by Holger Keding, Synopsys, Inc., 26 Jan 2002.This README contains the following sections: 0.    Getting Started0.1   .. Getting Started for Unix0.2   .. Getting Started for Windows1.    Introduction : the bus model1.1   .. Bus Interface1.1.1 .... Blocking Interface1.1.2 .... Non-Blocking Interface1.1.3 .... Direct Interface1.2   .. Slave Interface1.3   .. Arbiter1.4   .. Timing1.4.1 .... Blocking Request1.4.2 .... Non-Blocking Request1.4.3 .... Direct Request1.5   .. Interfaces Used1.5.1 .... Bus1.5.2 .... Arbiter2.    The Testbench2.1   .. Slaves2.1.1 .... Fast Memory Slaves2.1.2 .... Slow Memory Slaves2.2   .. Masters2.2.1 .... Non-Blocking Masters2.2.2 .... Blocking Masters2.2.3 .... Direct Masters2.3   .. The Test 'Schematic'2.3.1 .... Construction2.3.2 .... Simulation2.4   .. Runtime Behavior2.4.1 .... Direct Master2.4.2 .... Non-Blocking Master2.4.3 .... Blocking Master2.5   .. Running3.    Files-----------------------------------------------------------------------------0. Getting Started0.1 Getting Started for UnixThe simple bus example is now part of the SystemC distribution. It islocated in directory 'examples/systemc/simple_bus'. To be able to runthe example, first go to this directory and build the executable,e.g.  For gcc-2.95.2 on Solaris:  > gmake -f Makefile.gcc  For SC6.1 and SC6.2 on Solaris:  > gmake -f Makefile.sun  For gcc-2.95.2 on Linux:  > gmake -f Makefile.linux  For aCC (A.03.15 and A.03.31) on HP-UX:  > gmake -f Makefile.hpNow you can run the executable, e.g.  > simple_bus.x0.2 Getting Started for WindowsThe simple bus example is now part of the SystemC distribution. Thesource code of this example is located in directory'examples/systemc/simple_bus'. Project and workspace files for VisualC++ are located in directory 'msvc60/examples/simple_bus'. To be ableto run the example, go to this directory and double-click on thesimple_bus.dsw file to launch Visual C++ with the workspace file. Theworkspace file will have the proper switches set to compile for VisualC++ 6.0. Select 'Build simple_bus.exe' under the Build menu or pressF7 to build the simple_bus executable.Now you can select 'Execute simple_bus.exe' under the Build menu orpress Ctrl+F5 to run the simple_bus executable.1. Introduction : the bus modelThis is the description of a simple abstract bus model. The modelingis done at the transaction level, and is based on cycle-basedsynchronization.Cycle-based synchronization: This reduction in timing accuracy resultsin high simulation speed. The goal is to model the organization anddata movement in the system on a clock by clock basis, as compared tothe equivalent real system. Sub-cycle events are then of no interest.Transaction modeling: The communication between components aredescribed as function calls. Events or sequences of events on a groupof wires are represented by a set of function calls in an abstractsoftware interface. Transaction modeling of the interfaces enableshigher simulation speed than pin-based interfaces and also speeds upthe modeling construction process. This example design uses an overall form of synchronization wheremodules attached to the bus execute on the rising clock edge, and thebus itself executes on a falling clock edge. This is a modelingtechnique used to achieve very high simulation performance forabstract bus models, it does not imply that the actual implementationof this design must use a bus that is sensitive to the falling clockedge. The final implementation may in fact only have a single clockwith all logic sensitive only to the rising edge. Othersynchronization schemes (e.g. reliance on primitive channels and therequest_update/update scheme) could also have been used, though likelythey will result in more complicated and slower code for this design.1.1 Bus InterfaceThe Bus Interface describes the communication between masters and thebus. To the bus multiple masters can be connected. Each master isidentified by a unique priority, that is represented by an unsignedinteger number. The lower this priority number is, the more importantthe master is. Each bus interface function uses this priority to setthe importance of the call. There are three sets of communicationfunctions (interfaces) defined between the masters and the bus:blocking, non-blocking and direct. A master can reserve the bus for a subsequent request by using alock flag. If this flag is set and the request is granted at a givencycle, then the bus will be locked for the same master in thefollowing cycle if that master issues another request.1.1.1 Blocking InterfaceThe blocking interface functions move data through the bus inburst-mode, and are defined as follows: simple_bus_status burst_read(unsigned int unique_priority,	 		     int *data,			     unsigned int start_address,			     unsigned int length = 1,	 		     bool lock = false);simple_bus_status burst_write(unsigned int unique_priority,	 		      int *data,			      unsigned int start_address,			      unsigned int length = 1,	 		      bool lock = false);These functions read or write a block of data words (32bit), pointed to by data of size length (in words) from or to start_address. We areusing byte addressing here, i.e. each valid word address is a multipleof four. The value unique_priority specifies the importance of the master as well as the id of the master. If lock is set, there are two separate effects: 1) The function 'reserves' the bus for exclusive use for a next    request of the same master. This request must follow immediately    after the previous burst request is completed, i.e., when the    burst_read() or burst_write() function returns. 2) The function (i.e. the transaction) cannot be interrupted by a    request with a higher priority.After completion the bus returns a simple_bus_status that is one of:- SIMPLE_BUS_OK    : Transfer succeeded.- SIMPLE_BUS_ERROR : An error occurred during the transfer. Not all                     data could be read/written.Examples of conditions which might result in SIMPLE_BUS_ERROR includeillegal addresses or address ranges, and writing to a read-only slave.Note that interruption of a transaction does not result inSIMPLE_BUS_ERROR.1.1.2 Non-Blocking InterfaceThe non-blocking interface functions are defined as follows:void read(unsigned int unique_priority,	  int *data,	  unsigned int address,	  bool lock = false);void write(unsigned int unique_priority,	   int *data,	   unsigned int address,	   bool lock = false);simple_bus_status get_status(unsigned int unique_priority);These functions read or write a single data word, pointed to bedata at address. The request is handled according the givenunique_priority. If lock is set, the function 'reserves' the bus forexclusive use for a next request of the same master. This request mustfollow immediately after the previous request is completed, i.e. whenthe get_status() function returns SIMPLE_BUS_OK or SIMPLE_BUS_ERROR. The functions return immediately. The caller must take care ofchecking the status of the last request, using the functionget_status(). This function queries the bus for the status of thelast request made to the bus. Also here the unique_priority of themaster must be passed in order to get the status of the appropriaterequest. The status of the request is one of:- SIMPLE_BUS_REQUEST : The request is issued and placed on the queue,                       waiting to be served.- SIMPLE_BUS_WAIT    : The request is being served but is not completed                       yet.- SIMPLE_BUS_OK      : The request is completed without errors.- SIMPLE_BUS_ERROR   : An error occurred during processing of the                       request. The request is finished but the                        transfer did not complete successfully.A new non-blocking request can be made if the status of the (last)request is either SIMPLE_BUS_OK or SIMPLE_BUS_ERROR. Immediately afterissuing the request, the status becomes in all casesSIMPLE_BUS_REQUEST. The status only changes when the bus processes therequest. When a new request is issued and the current one is notcompleted yet, an error message is produced and the execution isaborted.1.1.3 Direct InterfaceThe direct interface functions are defined as follows and are the samefor the bus interface and the slave interface:bool direct_read(int *data,                 unsigned int address);bool direct_write(int *data,	          unsigned int address);The direct interface functions perform the data transfer through thebus, but without using the bus protocol. When the function is invoked,the transfer takes place immediately. The return status is either:- true  : The transfer was successful.- false : The transfer was not successful. Possible cause is that the          given address cannot be mapped upon a slave, or the memory 	  location cannot be read or written.1.2 Slave InterfaceThe slave interface describes the communication between the bus and theslaves. To the bus multiple slaves can be connected. Each slave modelssome kind of memory that can be accessed through the slave interface.The slave interface is defined by two sets of functions. The first setserves the default operations of read/write data to and from memory,while the second set of functions describe the direct interface,hereby ignoring possible wait states of the slaves. The directinterface is already discussed in section 1.1.3.The normal-mode functions are defined as follows:simple_bus_status read(int *data,		       unsigned int address);simple_bus_status write(int *data,			unsigned int address);These functions read or write a single data element, pointed to bydata in or from the slave's memory at address. The functions returninstantaneously and the caller must check the status of the transfer bychecking the return value of the functions. If the returned status isSIMPLE_BUS_WAIT, the caller must call the function again until thestatus changes. The status of the interface functions in one of:- SIMPLE_BUS_WAIT  : The slave issued a wait state.- SIMPLE_BUS_OK    : The transfer was successful.- SIMPLE_BUS_ERROR : An error occurred during the processing of the                     transfer. The transfer is finished but was not                     successful. If the slave models one or more wait states, the status of theinterface function will be SIMPLE_BUS_WAIT; in case of an error thestatus will be SIMPLE_BUS_ERROR and the transfer is aborted. Eachsubsequent cycle the status must be checked again until the statusbecomes SIMPLE_BUS_OK. Only then the transfer is completed and theslave is ready to accept a next request.To obtain the memory range of a slave two functions are needed: unsigned int start_address() const;unsigned int end_address() const;The start_address function returns the address of the firstaddressable memory location of the slave; the end_address functionreturns the last addressable memory location of the slave.In the simple bus example these functions are used to perform a checkfor overlapping address spaces of the slaves before the simulation starts and to determine the appropriate slave for the specified address of a bus request.