Site Map

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.

Example

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.

Example

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

Example

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?

Example

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:

uml.pdf

Example

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.


CrossbarControlYaml Class

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.

Example

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. 

Example

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

/**
 * @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

/**
 * @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


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.


Example

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.

Example

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
.........




  • No labels