IP11

OVERVIEW

The SCPS framework provides a flexible inter-communication means, among compliant test instruments, permitting ease of management of inter-dependent and intra-modular task sets, resorting to the I2C bus standard. Interlinking of analog, mixed-signal and sensor test instrument is the main target; however, the IP also provides advantages for standalone cores through syntax simplification. The SCPS Controller implements the control state machine required to translate the SCPS instructions into I2C bus operations, as well as manage the associated registers and mechanism.

DESCRIPTION OF THE IP ARCHITECTURE

The proposed IP interprets I2C transactions as a means for instrument specific control logic management, through the update of a structured set of registers/pointers; permitting the sequencing of inter/intra-modular task sets.

 MODULE 1 – I2C Interpreter and I2C register bank

An I2C compliant sequence interpreter module serves as gateway for I2C transaction RX/TX. Optionally a set of I2C exclusive registers or instrument related I2C reachable registers can be accessible through such module.

 MODULE 2 – SCPS interpreter

This module serves to identify formatted SCPS transactions and provided necessary I2C related signal complementation. Additionally, the interpreter module serves as SCPS transaction processor, generating the appropriate actions for the SCPS Register module state actualization.

 MODULE 3 – SCPS Registers

Implements mandatory and optional registers/pointers involved in SCPS operations, including addressing and storing of parameters.

 MODULE 4 – SCPS Handler

An optional add-on that serves as a state extendable library, as to manage controllability and observability through analog, mixed-signal and/or sensor elements, as well as instrument specific functionality.

 MODULE 5 – Instrument Specific

Refers to all instrument specific logic or analog related elements.

IP CONTROL INSTRUCTIONS

• The associated SCSP instructions, which are introduced through SCSP Write Transactions or SWT (an I2C structured SCSP command write sequence) are divided in four categories: SETUP, CAPTURE, PROCESS, and SCAN (such categories are so named because of the SCPS framework methodology, however they represent four distinct instruction types independently of the scheme utilized). Each instruction follows specific updates of the associated flags, registers and pointers, and can target global, group or member modules.
• The SCPS Read Transactions or SRT, have specific responses depending on the current valid command (SWT introduced), as to permit a simplification of the transfer of data. The SRT are directly related to I2C read request, however follow an alternate response sequence which can involve multiple modules operations, including inter-modular data transfer (i.e. inter-slave data transfer from an I2C perspective).

IP TEST MESSAGES

• STATUS register, accessible through command related SRT reflecting command state, lock state, fault conditions and additional operation related states.
• Optional: Extended Fault Registers and Process Registers provide additional operation related information.
• Instrument specific response.

VALIDATION RESULTS

Sensor degradation and fault detection based on threshold were considered as testing scenarios. A field programmable gate array (FPGA) based modular implementation was developed considering two case-studies: force sensing resistors (FSR) and disposable biopotential Ag-AgCl electrodes. The stratagem was executed using the inter-integrated circuit (I2C) bus protocol, while an independent I2C controller for instruction handling was utilized for proof of concept scenario. Additionally, external access to the data transport bus, utilized for debugging and testing purposes, was achieved through direct access to the implemented FPGA modules registers through an USB connection, managed by a Python based graphical user interface. The target sensors were impedance characterized in a number of common degradation scenarios in order to ascertain base models as to establish deviations.

Additional validation was performed through inclusion in the built-in self-test of a electromyography mixed-signal front-end module of a wearable data acquisition system for gait analysis purposes;  the implemented tests cover the functional response of the associated signal conditioning circuitry and electrode-skin verification.