Attachment Filename - UTF-8''TI - DCA1000EVM - CLI - Software - DeveloperGuide
Attachment Filename - UTF-8''TI - DCA1000EVM - CLI - Software - DeveloperGuide
DCA1000EVM CLI
Software Developer Guide
Revision 1.01
<10-Apr-2019>
www.ti.com
Revision History
Contents
1 Introduction ...........................................................................................................................................................6
1.1 Purpose & Scope ..................................................................................................................................................6
1.2 Terms / Acronyms / Abbreviations ......................................................................................................................6
1.3 Audience ..............................................................................................................................................................7
1.4 DCA1000EVM CLI & DLL Overview ......................................................................................................................8
2 DCA1000EVM Architecture Overview ...................................................................................................................9
2.1 System Block diagram ..........................................................................................................................................9
2.2 CLI Process .........................................................................................................................................................10
2.2.1 CLI Control Tool Process .............................................................................................................................10
2.2.2 CLI Record Tool Process ..............................................................................................................................12
2.2.2.1 Start Record Sequence .......................................................................................................................12
2.2.2.2 Stop Record Sequence ........................................................................................................................14
2.2.3 Inter-process Communication ....................................................................................................................19
2.2.3.1 Shared memory ..................................................................................................................................20
2.2.3.2 Socket IPC ...........................................................................................................................................22
2.2.4 JSON Config File ..........................................................................................................................................23
2.2.5 Output Files ................................................................................................................................................28
2.2.5.1 CLI logfile ............................................................................................................................................28
2.2.5.2 Record process datafile ......................................................................................................................28
2.2.5.3 Record process logfile.........................................................................................................................29
2.2.6 System Status Codes ...................................................................................................................................30
2.3 CLI Application Commands ................................................................................................................................33
2.3.1 Configure FPGA ...........................................................................................................................................34
2.3.2 Configure EEPROM .....................................................................................................................................36
2.3.3 Reset FPGA..................................................................................................................................................40
2.3.4 Reset RADAR EVM ......................................................................................................................................42
2.3.5 Start record .................................................................................................................................................45
2.3.6 Stop record .................................................................................................................................................48
2.3.6.1 User asynchronous stop record ..........................................................................................................48
2.3.6.2 DCA1000EVM asynchronous status stop record ................................................................................51
ACK Acknowledgement
GB Gigabit
IP Internet Protocol
LIB Library
PC Personal Computer
OS Operating System
UI User Interface
us Micro Second
1.3 Audience
Anyone interested in understanding the DCA1000EVM CLI design.
The DCA1000EVM CLI and DLL application performs configuration of DCA1000EVM and recording based on the
user inputs. Control commands will block waiting for the response till it gets timed out. The user input can be Linux
shell or a system call from another application or DOS prompt. CLI and DLL supports multiple instances if unique
port numbers are used.
There are two modes for application to integrate the DCA1000EVM functionality.
➢ Interacting with CLI
o Application shall send parameters in JSON formatted config file for the corresponding CLI Control
commands and shall support multiple data capture without closing the host application.
o CLI application supports both Windows and Linux
o Acknowledgement of commands and error codes are handled and returned by the CLI application
as a signed 32-bit integer value to the calling application. Calling application can also read the last
error code status returned by the CLI process using GetLastError() in windows and errno status in
Linux.
o The response status of each of the command is captured in a log file by the CLI application.
o CLI application supports running as a foreground as well as a background process.
DLL Module:
➢ DLL receives its configuration via set of APIs and uses that information to communicate with DCA1000EVM
system over Ethernet using UDP protocol.
➢ DLL supports 2 modes of record processing. Both record processing modes are mutually exclusive, and DLL
need to be compiled with any one of the processing modes. DLL does not support runtime changing of
record processing mode.
o Post processing – Data will be captured and stored in the file directly. Offline, the captured data
can be processed for zero filling of dropped packets and sorting of packets using post processing
utility. Then the processed data can be realigned using data alignment utility.
o Inline processing – Data will be captured and stored in the buffer. In parallel, the buffered data will
be processed for zero filling of dropped packets and sorting of packets. Then the processed data
will be realigned and stored in the files.
➢ DCA1000EVM_CLI_Control.exe
➢ DCA1000EVM_CLI_Record.exe
• User will initiate the control command through script or command line as
DCA1000EVM_CLI_Control <command> configFile.json
• If record process is running, CLI_Control tool will prompt the user to stop the already running record
process. The CLI_Control tool logs the information in a log file with timestamp and will be terminated.
• If no process is running, CLI_Control tool validates the input parameters from the configJsonfile.
• CLI_Control initializes the config port ethernet connection and send <command> and wait for response
packet till timeout.
• CLI_Control displays the command status to the user in the console. The CLI_Control tool also stores the
configuration command status in a log file with timestamp. The exit code of the last executed process can
also be read using OS system calls based on the calling application.
• CLI_Control tool initiates the Start record process by invoking CLI_Record tool. CLI_Control will poll the
shared memory for start command status and display the command status in the console and stores it in
log file with the timestamp. Then it terminates.
• CLI_Record tool initializes the config and data ports ethernet connection.
• CLI_Record tool handles the responses for start and stop commands and async packets from DCA1000EVM
and update the shared memory and in the console/logfile based on the running mode of the record process.
• For inline and post processing, CLI_Record tool updates the status of the dropped packets metadata in the
shared memory whenever any out of sequence packet is received through Ethernet.
• When recording is in progress, other control commands cannot be executed using CLI_Control tool until
stop command is issued. CLI_Control tool will prompt the user as ‘Stop the already running record process’
by reading status in shared memory.
• CLI_Control tool initiates the Stop record process by messaging the CLI_Record tool through socket IPC.
CLI_Control will send stop command to the config port which is listened by CLI_Record tool. Then
CLI_Record will send stop command to DCA1000EVM and updates the shared memory and in the
console/logfile based on the running mode of the record process.
• CLI_Control will poll the shared memory for stop command status and display the command status in the
console and stores it in log file along with timestamp.
• CLI_Record tool will overwrite at any point of the record process whenever data is transferred to or from
DCA1000EVM like async and start/stop config commands.
• CLI_Control tool can poll shared memory for record process at any point of time. CLI_Control will only read
the shared memory. CLI_Record tool will only write the shared memory.
Start and stop record process are detailed in the below section.
➢ CLI_Control tool will create the shared memory based on the unique config port and invoke the CLI_Record
tool.
➢ CLI_Record tool will bind to the config port and data ports.
➢ CLI_Record tool will send the start command to DCA1000EVM and handle its response.
▪ On successful start command response, record data will be captured in the files and CLI_Record
tool will update the status in shared memory as “Record is in progress”
▪ On failure/no response of start command, CLI_Record tool will update the status in shared
memory as “Start Command Failure/No Response”. CLI_Record tool will be terminated.
➢ CLI_Control tool will poll for the start command status for a defined time from shared memory.
➢ CLI_Control tool will update the start command status in the console and in the logfile and will be
terminated.
➢ CLI_Control tool will verify the record process status in shared memory.
▪ If no record process is running, CLI_Control tool will inform the user that no process is running to
stop and will be terminated.
▪ If any record process is in running state, CLI_Control tool will proceed through following steps.
➢ CLI_Control tool will use DLL to pass the stop message to CLI_Record tool over the local config port to stop
recording.
➢ On receiving the message, CLI_Record tool will use the DLL to send the stop command to DCA1000EVM
over the config port to stop the record data streamed over Ethernet from the DCA1000EVM.
▪ On successful stop command response, CLI_Record tool will read all the data in the socket buffer
and update the status in shared memory as “Record Stopped”. CLI_Record tool will be terminated.
▪ On failure/no response of stop command, CLI_Record tool will update the status in shared memory
as “Stop Command Failure/No Response”. CLI_Record tool will be terminated.
➢ CLI_Control tool will poll for the stop command status for a defined time from shared memory.
➢ CLI_Control tool will update the stop command status in the console and in the logfile and will be
terminated.
➢ The following asynchronous status from DCA1000EVM initiates the stop record command
▪ No LVDS data status
▪ No header status
▪ Record completed status
➢ On receiving any one of the above asynchronous status from DCA1000EVM, CLI_Record tool will use the
DLL to send the stop command to DCA1000EVM over the config port to stop the record data streamed over
Ethernet from the DCA1000EVM.
▪ On successful stop command response, CLI_Record tool will read all the data in the socket buffer
and update the status in shared memory as “Record Stopped”. CLI_Record tool will be terminated.
▪ On failure/no response of stop command, CLI_Record tool will update the status in shared memory
as “Stop Command Failure/No Response”. CLI_Record tool will be terminated.
➢ The following asynchronous status from DLL initiates the stop record command
▪ Timeout error status
▪ Record data file creation error status
▪ Reordering error status (inline processing)
}SHM_PROC_STATES;
}strRFDCCard_InlineProcStats;
Refer section 2.3.10 for more details on how CLI Control tool will read the shared memory.
{
"DCA1000Config": {
"dataLoggingMode": "raw",
"dataTransferMode": "LVDSCapture",
"dataCaptureMode": "ethernetStream",
"lvdsMode": 1,
"dataFormatMode": 1,
"packetDelay_us": 25,
"ethernetConfig": {
"DCA1000IPAddress": "192.168.33.180",
"DCA1000ConfigPort": 4096,
"DCA1000DataPort": 4098
},
"ethernetConfigUpdate": {
"systemIPAddress": "192.168.33.30",
"DCA1000IPAddress": "192.168.33.180",
"DCA1000MACAddress": "12.34.56.78.90.12",
"DCA1000ConfigPort": 4096,
"DCA1000DataPort": 4098
},
The min, max and default values for the JSON config file parameters are as follows:
Parameter Min Max Default Description
DCA1000Config - - - Object contains DCA1000EVM
related configuration
Calling Convention -
DCA1000EVM_CLI_Control.exe <command> [jsonCfgFile] [-q]
6. Timer (Not configurable using JSON file. Configured by DLL based on the value set in the structure)
Command:
Command JSON File data CLI calling DLL API calling convention
convention
Configure "dataLoggingMode": "raw", DCA1000EVM_ STATUS
FPGA "dataTransferMode": CLI_Control ConnectRFDCCard_ConfigMode
"LVDSCapture", fpga (
"dataCaptureMode": configFile.json strEthConfigMode sEthConfigMode
"ethernetStream", );
"lvdsMode": 1,
"dataFormatMode": 3, STATUS ConfigureRFDCCard_Fpga
"ethernetConfig": { (
"DCA1000IPAddress": strFpgaConfigMode sConfigMode
"192.168.33.180", );
"DCA1000ConfigPort":
4096, STATUS
"DCA1000DataPort": 4098 DisconnectRFDCCard_ConfigMode
} (void);
Command:
Command JSON File data CLI calling DLL API calling convention
convention
Configure "ethernetConfig": { DCA1000EVM STATUS
EEPROM "DCA1000IPAddress": _CLI_Control ConnectRFDCCard_ConfigMode
"192.168.33.180", eeprom (
"DCA1000ConfigPort": configFile.json strEthConfigMode sEthConfigMode
4096, );
"DCA1000DataPort": 4098
}, STATUS ConfigureRFDCCard_Eeprom
"ethernetConfigUpdate": { (
"systemIPAddress": strEthConfigMode sEthConfigMode
"192.168.33.30", );
"DCA1000IPAddress":
"192.168.33.180", STATUS
"DCA1000MACAddress": DisconnectRFDCCard_ConfigMode
"12.34.56.78.90.12", (void);
"DCA1000ConfigPort":
4096,
"DCA1000DataPort": 4098
}
Command:
Command JSON File data CLI calling DLL API calling convention
convention
Reset FPGA "ethernetConfig": { DCA1000EVM STATUS
"DCA1000IPAddress": _CLI_Control ConnectRFDCCard_ConfigMode
"192.168.33.180", reset_fpga (
"DCA1000ConfigPort": configFile.json strEthConfigMode sEthConfigMode
4096, );
"DCA1000DataPort": 4098
} STATUS ResetRFDCCard_FPGA (void);
STATUS
DisconnectRFDCCard_ConfigMode
(void);
Command:
STATUS
DisconnectRFDCCard_ConfigMode
(void);
Command:
Command:
Command JSON File data CLI calling DLL API calling convention
convention
STATUS DisconnectRFDCCard_
AsyncCommandMode (void);
Command JSON File data CLI calling DLL API calling convention
conventio
n
Stop Record "ethernetConfig": { NA STATUS
(Based on "DCA1000IPAddress": ConnectRFDCCard_RecordMode
DCA1000EV "192.168.33.180", (
M record "DCA1000ConfigPort": strEthConfigMode sEthConfigMode
completed 4096, );
status) "DCA1000DataPort": 4098
} STATUS StopRecordData (void);
STATUS DisconnectRFDCCard_
RecordMode (void);
Command:
Command JSON File data CLI calling DLL API calling convention
convention
Configure "packetDelay_us": 5, DCA1000EVM_ STATUS
Record "ethernetConfig": { CLI_Control ConnectRFDCCard_ConfigMode
delay "DCA1000IPAddress": record (
"192.168.33.180", configFile.json strEthConfigMode sEthConfigMode
"DCA1000ConfigPort": );
4096,
STATUS
DisconnectRFDCCard_ConfigMode
(void);
Table 18 Configure record delay calling convention
Command:
DCA1000EVM_CLI_Control.exe dll_version
Command JSON File data CLI calling convention DLL API calling convention
Command:
Command JSON File data CLI calling DLL API calling convention
convention
Read FPGA "ethernetConfig": { DCA1000EVM STATUS
version _CLI_Control ConnectRFDCCard_ConfigMode
STATUS
DisconnectRFDCCard_ConfigMode
(void);
Table 21 Read FPGA version calling convention
Command:
This command will also display in the console and log in the logfile when any of the async status is received while
recording is in progress.
Refer section 2.2.3.1 for record process states and 2.2.6 for system async status details.
Command JSON File data CLI calling DLL API calling convention
convention
Query "ethernetConfig": { DCA1000EVM_CLI_C NA
record "DCA1000IPAddress": ontrol query_status
process "192.168.33.180", configFile.json
status "DCA1000ConfigPort":
4096,
"DCA1000DataPort": 4098
}
Table 23 Query record process status calling convention
Command JSON File data CLI calling DLL API calling convention
convention
System "ethernetConfig": { DCA1000EVM_CLI_ STATUS
connectivity "DCA1000IPAddress": Control ConnectRFDCCard_ConfigMode
"192.168.33.180", query_sys_status (
"DCA1000ConfigPort": configFile.json strEthConfigMode sEthConfigMode
4096, );
"DCA1000DataPort":
4098 STATUS HandshakeRFDCCard(void);
}
STATUS
DisconnectRFDCCard_ConfigMode
(void);
Table 25 Query DCA1000EVM system status calling convention
Application interacting with DLL shall register a callback function for response handling, validation of parameters
status and other async status packets. The user event callback with the appropriate error message would be
invoked by the API/DLL/Library to communicate the responses, status or error back to the calling application.
Data
(Max – 1456 bytes)
Data
(Max – 1456 bytes)
➢ DCA1000EVM and DLL async status (Refer 2.2.6 for more details)
o On receiving the status from DLL, CLI Record tool will update the shared memory with the status.
o For the following 4 status, CLI Record tool will use DLL to send the stop command over the config
port to DCA1000EVM and will update the shared memory with the record process state. (Refer
section 2.2.3.1 for record process states).
▪ Record completed
▪ No LVDS data
▪ No header
▪ Reordering of data bytes failure
▪ Record file creation failure
o CLI Record tool will terminate after the stop record API returned the status.
Command JSON File data CLI calling DLL API calling convention
convention
Asynchronous NA NA STATUS StatusRFDCCard_EventRegister
status (
EVENT_HANDLER
RFDCCard_EventCallback
);
Command JSON File data CLI calling DLL API calling convention
convention
Record NA NA STATUS RecInlineProcStats_EventRegister
process status (
INLINE_PROC_HANDLER
RecordStats_Callback
);
2.4.3 Threads
➢ CLI_Control tool listens to the command response packets. If any record process is running, only stop and query
record process commands are allowed from CLI_Control tool. CLI_Control tool reads the status of the record
process from shared memory.
➢ DLL spawns 2 threads in raw mode data recording and 6 threads in multi-mode data recording when built for post
processing mode.
➢ Bytes
▪ DLL will be configured with the bytes stop mode and number of bytes to capture, when start record
command is sent to DCA1000EVM.
▪ On receiving the data packets, the number of bytes will be counted.
▪ If any one of the data ports receives the total bytes to be captured, DLL will send the record completed
status to the CLI Record tool.
▪ CLI Record tool will use the DLL to send the stop record command over the config port through Ethernet.
➢ Frames
▪ DLL will be configured with the frames stop mode and number of frames to capture, when start record
command is sent to DCA1000EVM.
▪ This mode is valid only in multi-mode data capture.
▪ On receiving the first packet, the Frame ID will be stored by DLL. The number of frames will be counted if
the frame ID is present in the received packet (Every new frame will be received as a new packet and hence
frame ID will always be the first 8 bytes of the data payload).
▪ If any one of the data ports receives the total frames to be captured, DLL will send the record completed
status to the CLI Record tool.
▪ CLI Record tool will use the DLL to send the stop record command over the config port through Ethernet.
➢ Duration
▪ DLL will be configured with the duration stop mode and duration in millisecond to capture, when start
record command is sent to DCA1000EVM.
▪ On receiving the first packet, the timer will be started by DLL.
➢ Infinite
▪ DLL will be configured with the infinite stop mode when start record command is sent to DCA1000EVM.
▪ Once the record completed status is received from the DCA1000EVM, DLL will send the record completed
status to the CLI Record tool.
▪ CLI Record tool will use the DLL to send the stop record command over the config port through Ethernet.
➢ When a packet is received at the data port, the packet is validated against out of order sequence. Following
information are getting updated in the shared memory.
▪ Out of sequence count
▪ First packet ID
▪ Last packet ID
▪ Number of received packets
▪ Capture start time
▪ Capture end time
▪ Capture duration
➢ Write the packet data into the file and move on to read the next packet till the record process is stopped.
Post processing need following two offline utility to process the captured data.
In post processing of record process, CLI application captures the data and stores in the files. The stored data should
be re-aligned to make reading of samples easier in post processing.
This utility needs to be run only if captured data is complex. It handles only Format 0 of the LVDS lanes.
For 2 channel data, the stored data will be like two 16-bit i data followed by two 16-bit q data. These data will be
realigned as one 16-bit I data followed by one 16-bit q data and so on.
For 4 channel data, the stored data will be like four 16-bit i data followed by four 16-bit q data. These data will be
realigned as one 16-bit I data followed by one 16-bit q data and so on.
When a packet is received, the packet is validated against out of order sequence.
If the packet is in sequence, write the packet data into the buffer and move on to read the next packet.
If the packet has the sequence number lesser than the expected next packet, seek through the buffer for the
packet offset and write the packet data into the buffer. Reset the buffer pointer and move on to read the next
packet.
If the packet has the sequence number greater than the expected next packet, calculate the number of packets
dropped. Fill the data size with zeros and write the packet data into the buffer and move on to read the next
packet.
Once the buffer 1 is full, start the file write process using the buffer 1. In parallel, move on to read the packet and
fill the received packet in the buffer 2. Once the buffer 2 is full, wait till the previous file write has been completed
and start the file write process using the buffer 2. In parallel, move on to read the next packet. Looping the process
till record stop is done.
The captured data in the buffer will be re-aligned to make reading of samples easier. After writing the reordered
data to the file, update the log file with the log buffer information.
2.5 FPGA
The DCA1000EVM DLL encapsulates all the details needed to configure and communicate with the FPGA including
reading of the RADAR data over the socket(s). This section will give an overview of the FPGA protocol and high-
level implementation for users looking to bypass the DLL and have a need to communicate with the FPGA directly.
DCA1000EVM system contains Lattice ECP5 FPGA to capture/deserialize LVDS data and forwards to host through
Ethernet UDP protocol. Following are the different modules in FPGA data processing.
▪ LVDS module receives 16-bit serial data from TI RADAR EVM and converts it into parallel data.
▪ DDR3 user interface module commands and controls the DDR3 IP based on data availability from LVDS
deserializer module.
▪ Data segregator module reads data from DDR3 and does following actions.
o Raw mode: Just forwards data to Ethernet through ADC data port.
o Multi-mode: Checks for data type and forwards data to Ethernet through corresponding UDP port.
Ethernet Module:
▪ This module takes the information coming from data segregator module and creates UDP Ethernet packet
as shown in figure-29 and forwards to GUI.
▪ RF Data Capture card sends 4 bytes of sequence number, 6 bytes of byte count and maximum 1456 bytes
of payload. Maximum payload size is set to 1456 to maintain I and Q alignment in a packet.
▪ Below two figures shows the data format which is stored in data segregator buffer. This data will be read
as 8-bit (starting from LSB to MSB) and transmitted over Ethernet.
1.
Raw Mode:
▪ Data segregator module reads data from internal buffer and sends following information to UDP packet
creation module.
o UDP port number – it is always ADC data port number for raw mode
o 4 bytes of sequence number for every packet
o 6 bytes of byte count – provides information about number of bytes transmitted till last packet.
Multi-Mode:
▪ Data segregator module reads data from internal buffer and checks for header types mentioned in Table-
27.
▪ Table-27 shows different data types which are supported by RF Data Capture card.
Identifier (64 bits) UDP port
0x0ADC0CDA0ADC0CDA “Raw data port”
0x0ADD0DDA0ADD0DDA
0x0ADE0EDA0ADE0EDA
0x0ADF0FDA0ADF0FDA
0x0CC909CC0CC909CC “Raw data port” + 1
0x0CC808CC0CC808CC “Raw data port” + 2
0x084f0f48084f0f48 “Raw data port” + 3
0x0C67076C0C67076C “Raw data port” + 4
▪ Table-28 and Table-29 shows multi-mode ADC data format for 4-lane and 2-lane boards.
▪ In multi-mode, data is received along with header which contains data identifier and length field.
▪ Length field provides the byte count which will be received followed by the header.
▪ After processing, both header and data are transmitted to GUI.
▪ Data segregator module sends following information to UDP packet creation module.
o UDP port number – it can be ADC/CP/CQ/R4F/DSP port number, depends on the header type
received.
o 4 bytes of sequence number – provides packet number. Separate sequencer count is available for
each data port.
o 6 bytes of byte count – provides information about number of bytes transmitted till last packet.
Separate byte count is available for each data port.
o Payload data – maximum 1456 bytes.
▪ Minimum byte count for processing the data is set to 48 bytes since the data separated mode has been
tested with minimum capture size of 48 bytes.
▪ This module waits for minimum 48 bytes of data to be available in buffer and then starts reading data from
buffer.
▪ If waiting time is more than 2s and data available in buffer is less than 48 bytes, this module reads the
available data and processes it (data type and length field identification).
UDP packet length is decided based on the length field available in multi-mode header. If length of the frame is
more than 1456, the frame payload data is split into multiple packets. The next frame will be sent as a new packet
with the multi-mode header ID.