V3.0 - Top-Level Requirements

[ReinhardKeil]

This is a list of the top-level requirements for SDS v3.0

Add sdsFlags

sdsFlags enable configuration options and compact diagnostic storage in a single word, enabling very fast checking, logging, and transmission of system information. sdsFlags can be modified by the SDS application or by the SDSIO-Server. Therefore the sdsFlags need to be send/received (via the SDSIO module) with the host computer using the SDSIO-Server. This information exchange should not sacrifice recording performance.

It is proposed to use:

• sdsFlags.31 = 1 for start of the SDS recording/playback I/O.
• sdsFlags.30 = 1 for terminating a CI run (on FVP simulation models or pyOCD)
• sdsFlags.29 = 1 for Playback mode
• sdsFlags.24...28 reserved for future enhancements
• sdsFlags.0..23 for user options (i.e. bypassing filter, ect.)

Details see: #207

SDS user interface only via SDSIO module

Currently SDS requires a debug STDIO for (a) diagnostics and (b) start/stop control. Both features should be enabled via the SDSIO-Server (so that this is the only required communication channel with the host computer. In addition error status should be displayed.

Example SDSIO-Server interaction:

Flags: 0x1                                    # Output sdsFlags status
SDS playback ML_In.case1.sds started
Flags: 0x5 [X]   Idle=56%                         # During I/O output rotating characters [/-\]
SDS_ERROR_IO: sds.c#23                        # Output error messages
SDS playback ML_In.case2.sds started     

Pragmatic user control via console I/O:

• a clear bit 0, A set bit 0 (using the letters A...H for the first 8 bits).
• s clear bit 31 (stop recording), S set bit 31 (start recording)

Only one LED used:

Only one LED is blinking: with 0.5Hz when idle, 5Hz when I/O is in progress.

UART output optional:

Introduce SDS_STDIO with default #define SDS_STDIO 1, when set to 0 no UART is used.

Details see: #178 + #207

SDSIO-Server USB can be connected any time

Currently the SDSIO-Server needs to be started before the SDS application. This should be not required in USB mode.

See: #195

Record/Playback in same image

sdsFlags.29 = 1 is always set in Playback mode. This Flag can be used to switch dynamically between Record and Playback mode which effectively means that the SDSIO-Server can be started multiple times without the need to flash a different image:

Example:

>sdsio-server usb                                        # record new SDS files
>sdsio-server usb -c path/my.sdsio.yml      # playback SDS files

SDSIO Playback allows scripting

When using SDSIO-Server in playback mode, there should be a way to control the recording and playback directory, the data streams for playback along with the sdsFlags. There is already a sdsio.yml file for the FVP implementation, however this should be consistent with the SDSIO-Server so that the playback works the same for FVP or hardware. For example

mode: [playback, record]  # playback is default when control file is used
verbose: 0...1            # 0 minimize output, 1 output details
rec-dir: <path>           # optional
play-dir: <path>          # optional
stream:                   # without stream: use label: 0 ... n
  - SetFlag: 0x1
    label: case1
  - ClrFlag: 0x5
    label: case2

Overall the I/O files for the different streams must have the same label.

For SDSIO Python tools add an option -c to specify the sdsio.yml control file, i.e. sdsio-server usb -c path/my.sdsio.yml

With verbose: 0 only the flags and stream label is output:

Play stream: case1 (Flags: 0x1, Idle=25%)
Play stream: case2 (Flags: 0) [X]                            # During I/O output rotating characters [/-\]

Details see: #191 + #207

Overall simpler user view to SDS

The files sds_control and algorithm need to be simpler. Only the items that relate to SDS should be prefixed with sds. The user algorithm code should not use the sds prefix.

This also includes that the directory structure is simplified, i.e.

Directory	Description
Include	Only contains the user visible include files, sds.h, sdsio.h, sdsio_client.h
source	Contains the core part of sds including internal headers
source/sdsio	Contains client implementations, configuration files for the client implementation are also located there

Details see: #188

Usability

It should be tolerated that the SDSIO-Server is started after the firmware. The SDSIO-Server should allow for USB, RTT, and Serial Interface:

• Restart of the client firmware when the server gets a new start (could be with a sdsFlag.Restart)
• Connect the server to an already running client system

For Socket mode it is accepted that the SDSIO-Server needs to be started before the firmware.

Other

• Playback will no longer be controlled using the file <name>.index.txt.
• Overall a better consistency should be achieved:
  • Example: sds-check parameter -s should be -i to be consistent with other utilities
• timestamp will be renamed into timeslot. In playback the timeslot is used to synchronize the recording files, i.e. all output streams should have the same timeslots as the first input stream.
• Consider a RTT implementation of an sdsio client (that preferable works with Segger J-Link and pyOCD) (see RTT implementation for Segger J-Link and pyOCD #213)