SmartIO (Smart I/O)

General Description

The Smart I/O driver provides an API to configure and access the Smart I/O hardware present between the GPIOs (pins) and HSIOMs (pin muxes) on select device ports.

The functions and other declarations used in this driver are in cy_smartio.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.

It can be used to perform simple logic operations on peripheral and GPIO signals at the GPIO port. Features include,

1. Purely combinatorial logic using 8 Look-Up Tables (LUT).
2. Mixed sequential and combinatorial logic using 8 LUTs and 1 Data Unit (DU).
3. Counters and shift registers using 8-bit multi-function DU (simplified ALU).
4. Operational in device active, sleep and deep-sleep power modes.

Configuration Considerations

Routing Fabric

The Smart I/O routing fabric is divided into two portions, where each portion is capable of accepting half of the data or GPIO signals. The LUTs have the following structure.

• LUT 7...4 are capable of accepting signals from io/chip 7...4 as inputs.
• LUT 3...0 are capable of accepting signals from io/chip 3...0 as inputs.
• The LUTs can accept any LUT output as an input.
• Each LUT output is dedicated to the corresponding output io/chip terminal. For example, LUT 0 can go to either io0 terminal output or chip0 terminal output or both.

Single Source LUT Input

If a LUT is used, all three inputs to the LUT must be designated. For example, even If a LUT is used to accept a single source as its input, all three inputs must accept that same signal. The lookup table should then be designed such that it only changes the output value when all three inputs satisfy the same condition. For example, consider the case where the signal on data0 must be inverted before being passed to io0. LUT0 accepts chip0 as input 0, 1 and 2. The truth table is defined such that it outputs a logic 1 only when the inputs are all 0.

Clock and Reset Behavior

The Smart I/O hardware drives its synchronous elements using a single clock source. Depending on the clock source, the Smart I/O will have different reset behaviors, which will reset all the flip-flops in the LUTs and synchronizers to logic 0. The configuration registers will retain their values unless coming out of Power on Reset (POR). Notes:

• If the block is only disabled, the values in the LUT flip-flips and I/O synchronizers are held as long as the chip remains in a valid power mode.
• The selected clock for the fabric's synchronous logic is not phase aligned with other synchronous logic on the chip operating on the same clock. Therefore, communication between the Smart I/O and other synchronous logic should be treated as asynchronous (just as the communication between I/O input signals and other synchronous logic should be treated as asynchronous)

Clock Source	Reset Behavior	Enable Delay	Description
io/chip 7...0	Reset on POR	2 clock edges	If chosen as the clock source, that particular signal cannot also be used as an input to a LUT as it may cause a race condition. The fabric will be enabled after 2 clock edges of the signal on the gpio terminal.
Divided Clock (Active)	Reset when going to Deep Sleep, Hibernate or POR	2 clock edges	The fabric will be enabled after 2 clock edges of the divided clock. Any synchronous logic in the LUTs will be reset to 0 when in chip deep-sleep or hibernate modes.
Divided Clock (Deep-Sleep)	Reset when going to Hibernate or POR	2 clock edges	The fabric will be enabled after 2 clock edges of the divided clock. Any synchronous logic in the LUTs will be reset to 0 when in hibernate mode.
Divided Clock (Hibernate)	Reset on POR	2 clock edges	The fabric will be enabled after 2 clock edges of the divided clock.
LFCLK	Reset when going to Hibernate and POR	2 clock edges	The fabric will be enabled after 2 clock edges of the low frequency clock (LFCLK). Any synchronous logic in the LUTs will be reset to 0 when in hibernate mode.
Asynchronous	Reset on POR	3 clock edges of SYSCLK	The fabric will be enabled after 3 clock edges of the clk_peri source.

Signal Synchronization Requirement

If any of the signals coming in through the Smart I/O terminals are meant to be used in sequential elements in the LUTs, the terminal synchronizer must first be used to synchronize that signal to the Component clock. For example, if the signal on io0 must be used in LUT0 in Sequential output mode, the synchronization for io0 terminal should be enabled for reliable operation.

LUT Combinatorial Feedback

Since the LUTs can be configured as purely (or partially) combinatorial elements and since they can chain to each other in any fashion, combinatorial timing loops can occur. This causes oscillations that burn power and create unpredictable behavior. If a feedback is required, the signals should always go through a flip-flop before feeding back. For example, the following is a potentially problematic design; LUT1 and LUT2 are configured in combinatorial mode, where their respective outputs feed into the inputs of the other. This will result in oscillations. To prevent it, one of the LUTs should be configured to Gated Output mode.

Low Power Mode

The Smart I/O hardware is capable of operating during chip Deep-Sleep mode. The block has the following requirements when operating in this mode:

• All sequential elements must be clocked by a valid clock in these power domains. Refer to Clock and Reset Behavior for more details.
• All signals in the block (including the clock) must be less than 1 MHz when in Deep-Sleep mode.
• The hold override functionality should be enabled when entering Deep-Sleep mode. This functionality should then be disabled when the chip is not in this mode.

More Information

Refer to the technical reference manual (TRM) and the device datasheet.

MISRA-C Compliance]

MISRA Rule	Rule Class (Required/Advisory)	Rule Description	Description of Deviation(s)
10.3	R	The value of a complex expression of integer type shall only be cast to a type of the same signedness that is no wider than the underlying type of the expression.	Use of a Cypress defined macro to access memory-mapped objects.
11.4	A	Casting to different object pointer type.	Used at the device hardware register structure pointers for mapping to the IP type in the device.
16.7	A	A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object.	Base address pointers are always constant in drivers. No need to pick and choose const declaration based on function construction.

Changelog

Version	Changes	Reason for Change
1.0.1	Minor documentation updates.	Documentation enhancement.
1.0	The initial version.

API Reference
	Macros
	Functions
	Data Structures
	Enumerated Types