This is the beta version of the new stand-alone OCP TL2 channel model.

Performance First:
=================
The new OCP TL2 channel was created to be a stand-alone, faster channel
implementation. 

For performance reasons, the internals of the channel have been changed and
this has led to a few changes to the channel's API which are detailed below. 
Models written to the original OCP TL2 API should work with this new channel
model as long as changes below (OCP Parameters, Reset, and Sideband) are
implemented.  Models written to the new OCP TL2 API will run even faster.

New Commands:
============
The new stand-alone OCP TL2 channel model supports a new TL2 API. This
API is streamlined to be TL2 specific and should be easier to use with
better performance. If you are writing a new model, use this API.
Also note that the new TL2 request and response classes are compatible
with the original TL2 classes. See the member function "copyFrom" for
the built in coversion code.  Finally, the new OCP TL2 is backward
compatible with the original OCP specific TL2 channel. All of the
original OCP specific commands for the original channel are supported by
the new channel.

OCP Parameters:
==============
The new TL2 channel gets its OCP parameters from the OCPParameters class
in ocp_param.h. Note that this is not a templated class. Pointers to the OCP
parameter class should be changed as follows:

    // Old style OCP parameter class:
    // ParamCl<OCP_TL2_DataCl<unsigned int, unsigned int> > *pcl = ch0.GetParamCl();

    // New OCP TL2 style OCP parameter class (no template):
    OCPParameters *pcl = ch0.GetParamCl(); 

Also, the new OCPParameters class only contains OCP Parameters. Core parameters
such as "MasterID" and "EndAddress" are no longer available from the channel. For further details, please see the include file "ocp_params.h"

Reset:
=====
The commands MResetAssert(), MResetDeassert(), SResetAssert(), SResetDeassert(),
and getReset() are all supported, as are the older generic reset functions.
Reset is now a low-overhead operation. For performance reasons, the TL2 
API commands do not check for reset each time they are called. Asserting reset
causes the ResetStartEvent() to be activated, sets an internal channel state,
and nothing else. "Blocking" commands may lock-up under reset. It is up to
the cores to accept all requests/responses when a reset occurs and not to
issue new requests/responeses. In general, a system simulation that does not
use the reset function of the channel will run faster.

Sideband:
========
The new stand-alone channel supports all of the TL2 sideband commands. Note that
two of the sideband events have been changed. the SidebandStatusEvent and 
SidebandControlEvent have been replaced by SidebandCoreEvent and 
SideBandSystemEvent. SideBandCoreEvent is triggered whenever the "Core" side
of the channel sets a "sys/core" sideband field. Similarly, the 
SidebandSystemEvent is triggered whenever the "System" side of the channel
sets a "sys/core" sideband field. These new events follow the same pattern
as SidebandMasterEvent and SidebandSlaveEvent.

Transaciton Logging:
===================
The new OCP TL2 channel supports transaction logging through a stream pointer
passed by the user. See the channel's constructor for details. The 
transaction logging also does run time checking, matching requests to responses
within each OCP thread. As a result, transaction logging is a very useful
debugging aid.  Note that compiling the channel in performance mode 
automatically disables transaction logging - even if a transaction log
stream pointer is passed to the channel's constructor. In order to use
transaction logging, the NDEBUG flag must not be defined.

Performance Mode:
================
The channel can be compiled in performance mode by defining the compile flag
NDEBUG. In performance mode, the channel does no run time checking and no 
transaction logging. This allows the channnel to run as fast as possible. 
However, a system should be debugged first before being compiled into 
peformance mode. 

No DataCl, CommCl, or DirectIF support:
======================================
These generic channel base classes are not part of the stand-alone channel
and thus access to them is no longer available. Note that the access functions
to these classes were not part of the original OCP TL2 API either.

Generic Channel Commands:
========================
The stand-alone TL2 channel does not support the generic-style commands that
set request and response fields in the channel with one command and then 
activate the request or response with another command at a later time. Examples
would be: MputMData() and MputReadRequest(). If such a command is called,
the new stand-alone TL2 channel will print out an error message detailing 
which OCP TL2 command to use instead of the generic one.

Default Event:
=============
The new OCP TL2 channel does not have a default event.



