An I/O fabric contains all the logic and connectivity between the core of a chip and the chip pins. It typically contains all I/O cells, pin multiplexing logic, bounday cell logic and any other logic associated with the I/O layer.
Formerly known as the 'I/O ring', which contained basic I/O cells and minor glue logic, the I/O fabric has evolved into a complex and critical IP delivery within a SoC design flow. Due to the increasing complexity and sharing of I/O cells, the logic required for I/O cell control and pin multiplexing can be quite substantial. Aside from the multiplexing of standard I/O cell control signals, many I/O cells now have configurable skew, PUPD, power & reset etc, requiring flexible functional and DFT control.
The chip core can be defined as all the internal blocks and connectivity of the chip. The core interface typically contains all signaling associated the I/O function of the chip, including both functional and test I/O signaling as well as I/O cell control. Core pins can be defined at the signaling on the core interface that constitutes a single core pin. For example, at the core, three signals GPIO_IN, GPIO_OUT and GPIO_OEN would really only constitutes a single bidirectional pin, so this can be referred to as a "core pin."
The chip-top level represents the uppermost functional view (no physical mapping or power pads) of the SoC. Spinner also handles the mapping of these pins to die pads and consequently, package balls.
The I/O fabric typically contains core to chip-pin mappings which are implemented using multiplexers. Functional and test multiplexer logic needs to be split into separate paths in order to ensure that the timing critical functional path has the least number of gates. All possible M to N multiplexing options need to be supported along with the ability to prioritise particular Core Pins within the multiplexing logic. The multiplexing logic also supports both input and output paths. Input paths are protected to ensure that they are always driven to a pre-determined value when not selected in any multiplexing scenarios.
An I/O fabric may contain register configuration logic needed to control the behavior of the I/O logic. It should support the ability to place this I/O register decode logic within the Fabric or inside the chip's Core. The register control logic will define the selected multiplex logic and the control configuration for each of the I/O cells. The I/O fabric collateral should contain the necessary output formats needed to configure the I/O registers in a particular Chip I/O configuration (e.g. C header files).
An I/O Fabric will contain support for the Boundary Cell logic needed to support JTAG in-circuit testing methodologies. An I/O fabric must support the placement of Boundary Scan cells on all test paths. The hook-up of the JTAG TAP controller interface and control signals to the Boundary Scan cells must be supported. The I/O Fabric should handle flexible ordering of the BSR Chain along with the selection of subsets of the overall chain.
An I/O Fabric will contain daisy chain type connectivity between the I/O Cells in order to allow them to be activated or reset in a predetermined order.
An I/O Fabric must accommodate timing critical paths which need dedicated circuitry to ensure that timing constraints are met. In particular the I/O fabric must handle specialised signal paths such a clock and reset signals.
Where should an I/O Fabric fit into your design flow?
An I/O fabric is treated as an IP and in a design flow context includes not just the the RTL code but also collateral needed to support the full I/O Logic definition, validation and integration within an SoC design flow. An I/O Fabric needs to integrate closely with the SoC Core design as well as the System Test-bench methodology. The high level of configuability of the I/O fabric means that it will drive some of the HW/SW Register definition methodology as well as the back-end Die and Package layout and design methodology.
Thus the automation of the I/O Fabric methodology improves the productivity of all of teams which depend on the definition of the I/O Logic. It now needs to be treated an IP deliverable which can automatically be generated from a single source specification.
For more information on Spinner, download the Spinner Product Brief or return to the Spinner Product Page.