Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Site Map

Page Tree
rootPackage and module source code documentation
searchBoxtrue

Do you want to write a document describing the software and you're lost? If so, you are in the right place. This is a potential outline of what you may want to include in your document.

Package/module name as title

Here goes a simple description of of the package/module.

Info
titleExample
The common ATCA driver is an API that intermediates ATCACommon EPICS module and CPSW. It abstracts common ATCA registers and provides get and set functions to control them using CPSW. It also makes transparent all the peculiarities of CPSW.

Introduction

This contains a list of the capabilities of the module/package i detail. The reader should be able to understand the basic functionalities of this package/module by reading this text.

Info
titleExample

The common ATCA package is responsible for the following:

  • Connect to CPSW package and establish communication with the registers of the firmware common structure and are
    • DaqMux 0 and 1 configurations : Sends waveforms to software for visualization. Waveform source is configurable.
    • JESD Top (AMC) 0 and 1 : protocol communicating with ADC/DACs on the AMC cards
    • Waveform engine: An intermediate component between DaqMux (oscilloscope) and the software
    • bitstream build information
    • Temperature information
    • timing cross bar
  • Provide API class, once instantiated using static function, the user is permitted to control the registers and create and read streams

Package/module file structure

This section should contain the list of files and a simple description of each

Info
titleExample

The files in the package are as follows

  • atcaCommon.h: Contains definition of a base class IATCACommonFw class. 
  • atcaCommon.cc: Contains the implementation of new class CATCACommonFwAdapt that implements class IATCACommonFw. This class uses CPSW to establish communication with the DaqMuxes, waveform engines, ADC interfaces (JESD), and firmware information, and provides API functions to write/read to/from the registers.
  • crossbarControlYaml.hh: Defines class CrossbarControlYaml. This class uses CPSW to establish communication with the crossbar in hardware. It provides API functions to read and write to crossbar configurations.
  • crossbarControlYaml.cc: implements CrossbarControlYaml class

Operation (if applicable)

How does the package/module do what it does? Are there any YAML files? Are there any registers in the YAML files? Which are these registers and what do they represent?

Info
titleExample

The common ATCA package uses the common platform software package (establishes connections with hardware based on protocols and addresses described in YAML files). The API assumes that the CPSW YAML files were already read and parsed successfully. The API requires a path the denote where all the registers will reside. 

The YAMLs necessary for the correct operation of the common ATCA API are shown as follows

  • AppTop.yaml
  • ...

All the registers and streams that will be accessed are in the previously mentioned paths. A summary of the used registers are as follows:

Register IndexYAML FileStream/Register nameDescription
1AxiVersion.yaml

UpTimeCnt

Number of seconds since last reset
2BuildStampTimestamp of the FPGA build
3FpgaVersionFPGA firmware version
.........

Class(es)/file(es) descriptions

Each file/associated classes will be described here. UML diagrams and text description can be used. A UML cheat sheet can be found here. Good examples of how to represent relationship between classes can be found here. Instantiation information (if applicable) can be mentioned. Flow diagrams for describing the class operation are also welcome. Everything can be developed in Gliffy. 

This PDF is a good how-to to work with class diagrams:

View file
nameuml.pdf
height150

Info
titleExample

This class is responsible for configuring the timing cross bar. The timing cross bar is nothing more than four multiplexers configuring four outputs. The four outputs and the four inputs are as follows:

  • 0: NC TPG timing
  • 1: Mini TPG
  • 2: Back plane
  • 3: SC TPG timing

The UML diagram is shown as follows.


Gliffy Diagram
nameCrossbarControlYaml Class
attachmentId358223325
pageid358222322

The functions available are simply to instantiate a crossbar, and to configure and read current configuration

Exception handling (if applicable)

Here you can mention if the package/module throws any exceptions, and you can also mention how these exceptions should be handled in upper layers.

Info
titleExample
The package does not throw any exceptions. Nonetheless, CPSW throws CPSWError errors and the package propagates these exceptions. In these contexts the package prints to stderr. Upper layers should catch exceptions of type CPSWError.

Extension (if applicable)

Is the package extendable to add a new function or to modify an existing function? If so, it needs to be mentioned here. 

Info
titleExample

The functionality of debugStream could be extended to call one's own callback along with the default. The API function provided for registering the callback is in the debugStreamInterface.h header file and is as follows

Code Block
languagecpp
themeRDark
/**
 * @brief Register a callback when data arrives on a specific channel of stream
 *
 * @param portName : name of the asyn port generating the stream
 * @param stream_channel : Number of the channel to be parsed (1-4)
 * @param cb_func : callback function to register
 * @param cb_usr : private structure that will be passed to the callback
 * @return int : -1 if channel not found, else 0
 */
int registerStreamCallback(const char *portName, const int stream_channel, STREAM_CALLBACK_FUNCTION cb_func, void *cb_usr);


The callback function parameters have to be as follows

Code Block
languagecpp
themeRDark
/**
 * @brief Callback function format
 *
 * @param pBuf : buffer pointer
 * @param size  : size of buffer
 * @param time : Time of event
 * @param timeslot :  timeslot information from the timing pattern modifier
 * @param usr : user private object pointer
 */
void callback(void* pBuf, unsigned size,  epicsTimeStamp time, int timeslot, void* usr)


In order to read your own (custom stream), following these instructions

  1. Your driver class should inherit from DebugStreamAsynDriver class (and therefore will become an asyn driver)
  2. call the DebugStreamAsynDriver in the initializer list or the constructor of the asyn driver
  3. create your parameters in constructor
  4. Overload the virtual asyn write and read functions if necessary
  5. Overload the virtual streamPoll method of the parent class. This is where you will read and process the streams. 
  6. Create IOC shell command that instantiates your driver class

This is a streamPoll method example


Code Block
languagecpp
themeRDark
myStreamClass::myStreamClass(const char *portName, const char *named_root, const unsigned size, const bool header, const char *stream0, const char *stream1, const char *stream2, const char *stream3)
    : DebugStreamAsynDriver(portName,
                            named_root,
                            size,
                            header,
                            stream0,
                            stream1,
                            stream2,
                            stream3)
{
    createParam(p_myParamString,       asynParamFloat64, &p_myParam);
}
...



Exported IOC shell commands, description and parameters (if applicable)

All EPICS shell commands provided should be described here with their input parameters.


Info
titleExample

The IOC shell commands are as follows

Command

description

parameters

crossbarControlDriverConfigure

Configures crossbar in case PCIe is used, otherwise, does nothing

PCIe fixed configurations are

  • OutputConfig[0]: LCLS1 SFP loopback
    OutputConfig[1]: LCLS2 SFP loopback
    OutputConfig[2]: FPGA (LCLS1) <--- LCLS1 SFP
    OutputConfig[3]: FPGA (LCLS2) <--- LCLS2 SFP

  1. path for AmcCarrierCore

  2. root name (optional)
.........

PV name list (if applicable)

The PV list goes here. If any other page described some or all PVs, it can be referenced here. The register index can map the PV to the register described in the YAML section above.

Info
titleExample

Waveform engine PVs are shown here.

The remaining PVs are summarized as follows

Register index

PV name

Description

7-12$(DEVICE):JESD[1:0]_[7:0]Counts number of JESD re-synchronizations for the corresponding JESD lanes
1$(DEVICE):AMC_UPTIMECNTNumber of seconds since last reset
.........