readme

system C源码 一种替代verilog的语言

This is a simple version of an Abstract Bus Model. This version is
developed using SystemC 2.0, and is verified on all platforms supported
by 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 Started
0.1   .. Getting Started for Unix
0.2   .. Getting Started for Windows
1.    Introduction : the bus model
1.1   .. Bus Interface
1.1.1 .... Blocking Interface
1.1.2 .... Non-Blocking Interface
1.1.3 .... Direct Interface
1.2   .. Slave Interface
1.3   .. Arbiter
1.4   .. Timing
1.4.1 .... Blocking Request
1.4.2 .... Non-Blocking Request
1.4.3 .... Direct Request
1.5   .. Interfaces Used
1.5.1 .... Bus
1.5.2 .... Arbiter
2.    The Testbench
2.1   .. Slaves
2.1.1 .... Fast Memory Slaves
2.1.2 .... Slow Memory Slaves
2.2   .. Masters
2.2.1 .... Non-Blocking Masters
2.2.2 .... Blocking Masters
2.2.3 .... Direct Masters
2.3   .. The Test 'Schematic'
2.3.1 .... Construction
2.3.2 .... Simulation
2.4   .. Runtime Behavior
2.4.1 .... Direct Master
2.4.2 .... Non-Blocking Master
2.4.3 .... Blocking Master
2.5   .. Running
3.    Files

-----------------------------------------------------------------------------

0. Getting Started

0.1 Getting Started for Unix

The simple bus example is now part of the SystemC distribution. It is
located in directory 'examples/sysc/simple_bus'. To be able to run
the 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.hp

Now you can run the executable, e.g.

  > simple_bus.x

0.2 Getting Started for Windows

The simple bus example is now part of the SystemC distribution. The
source code of this example is located in directory
'examples/sysc/simple_bus'. Project and workspace files for Visual
C++ are located in directory 'msvc60/examples/simple_bus'. To be able
to run the example, go to this directory and double-click on the
simple_bus.dsw file to launch Visual C++ with the workspace file. The
workspace file will have the proper switches set to compile for Visual
C++ 6.0. Select 'Build simple_bus.exe' under the Build menu or press
F7 to build the simple_bus executable.

Now you can select 'Execute simple_bus.exe' under the Build menu or
press Ctrl+F5 to run the simple_bus executable.


1. Introduction : the bus model

This is the description of a simple abstract bus model. The modeling
is done at the transaction level, and is based on cycle-based
synchronization.

Cycle-based synchronization: This reduction in timing accuracy results
in high simulation speed. The goal is to model the organization and
data movement in the system on a clock by clock basis, as compared to
the equivalent real system. Sub-cycle events are then of no interest.

Transaction modeling: The communication between components are
described as function calls. Events or sequences of events on a group
of wires are represented by a set of function calls in an abstract
software interface. Transaction modeling of the interfaces enables
higher simulation speed than pin-based interfaces and also speeds up
the modeling construction process. 

This example design uses an overall form of synchronization where
modules attached to the bus execute on the rising clock edge, and the
bus itself executes on a falling clock edge. This is a modeling
technique used to achieve very high simulation performance for
abstract bus models, it does not imply that the actual implementation
of this design must use a bus that is sensitive to the falling clock
edge. The final implementation may in fact only have a single clock
with all logic sensitive only to the rising edge. Other
synchronization schemes (e.g. reliance on primitive channels and the
request_update/update scheme) could also have been used, though likely
they will result in more complicated and slower code for this design.


1.1 Bus Interface

The Bus Interface describes the communication between masters and the
bus. To the bus multiple masters can be connected. Each master is
identified by a unique priority, that is represented by an unsigned
integer number. The lower this priority number is, the more important
the master is. Each bus interface function uses this priority to set
the importance of the call. There are three sets of communication
functions (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 a
lock flag. If this flag is set and the request is granted at a given
cycle, then the bus will be locked for the same master in the
following cycle if that master issues another request.

1.1.1 Blocking Interface

The blocking interface functions move data through the bus in
burst-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 are
using byte addressing here, i.e. each valid word address is a multiple
of 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 include
illegal addresses or address ranges, and writing to a read-only slave.
Note that interruption of a transaction does not result in
SIMPLE_BUS_ERROR.

1.1.2 Non-Blocking Interface

The 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 be
data at address. The request is handled according the given
unique_priority. If lock is set, the function 'reserves' the bus for
exclusive use for a next request of the same master. This request must
follow immediately after the previous request is completed, i.e. when
the get_status() function returns SIMPLE_BUS_OK or SIMPLE_BUS_ERROR. 

The functions return immediately. The caller must take care of
checking the status of the last request, using the function
get_status(). This function queries the bus for the status of the
last request made to the bus. Also here the unique_priority of the
master must be passed in order to get the status of the appropriate
request. 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 after
issuing the request, the status becomes in all cases
SIMPLE_BUS_REQUEST. The status only changes when the bus processes the
request. When a new request is issued and the current one is not
completed yet, an error message is produced and the execution is
aborted.

1.1.3 Direct Interface

The direct interface functions are defined as follows and are the same
for 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 the
bus, 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 Interface

The slave interface describes the communication between the bus and the
slaves. To the bus multiple slaves can be connected. Each slave models
some kind of memory that can be accessed through the slave interface.

The slave interface is defined by two sets of functions. The first set
serves 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 direct
interface 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 by
data in or from the slave's memory at address. The functions return
instantaneously and the caller must check the status of the transfer by
checking the return value of the functions. If the returned status is
SIMPLE_BUS_WAIT, the caller must call the function again until the
status 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 the
interface function will be SIMPLE_BUS_WAIT; in case of an error the
status will be SIMPLE_BUS_ERROR and the transfer is aborted. Each
subsequent cycle the status must be checked again until the status
becomes SIMPLE_BUS_OK. Only then the transfer is completed and the
slave 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 first
addressable memory location of the slave; the end_address function
returns the last addressable memory location of the slave.

In the simple bus example these functions are used to perform a check
for overlapping address spaces of the slaves before the simulation 
starts and to determine the appropriate slave for the specified 
address of a bus request.