What does the "side-band" and "in-band" mean in the context of digital circuit?

Question

I read below content from the Intel On-chip System Fabric (IOSF) spec. AS I understand, the IOSF is a technology for chip reuse and interconnect.

The sideband message interface covers most communication that is not sent using inband transactions on the primary interface. Although IOSF allows sending in-band message transactions on the primary interface (such as interrupts and power management requests), some implementations may choose to use the sideband message interface instead.

I looked up the sideband, the explanation is from electric signal transmission context and seems not fit in.

So what does "side-band" and "in-band" mean in the quotation?

Answer 1

Many digital interfaces have more than one method of passing information. The main one is usually at high speed and takes the majority of the capability of the medium. Any information along this path is called "in-band".

However it is often necessary to communicate control or status information without disturbing the main data path - for example on HDMI there is the main video and sound transfer path but also a low speed I2C connection used to turn a TV or DvD player on or provide information on status- these are described as out-of band, or sometimes "side-band". This is completely different from the description you found that applies to modulation.

This out-of-band path may also be bi-directional even though the main data flow is unidirectional.

Answer 2

Look at the IOSF patent. https://patents.google.com/patent/EP2778930A2/en Focus on sections: [0016], [0015], [0018]. Specially the images it refers.

They define 3 channels to communicate among IP agents (Hardware blocks that group functionality). This interfaces connect to what they call the fabric. The fabric hardware handles communication between IPs, lets say it is a bus communication with steroids (for more details about the characteristics refer to the patent). Each ip has 3 blocks: side band interface, primary interface, DFx interface.

• "in-band" - traffic that uses primary interface.
• "side-band" - traffic that uses side band interface.
• "debug traffic" - traffic that uses DFX interface (see testability feature mentioned in patent)

Answer 3

I agree with you and thank you for the insight. Further, side-band message paths are generally added to system when new high speed in-band channel added into the IP.

Because, as you told, we don't know what are the issues in new in-band protocol/implementation. Also, to provision system using the high speed in-band path means, circuitry needs to be aware of two different messages

1. normal traffic
2. provisioning traffic/messages.

this complicates the whole. even it will start consuming little more power. (think, if our brain is guaranteed to hear 1 tune vs 2 tunes and respond. Obviously, brain needs make a lot effort just to distingwish.)

We generally think, adding two more pins for side band is costly. it is not the case. side band removes so much complexity from the main inband logic, gives a safer and proven ip (like i2c, spi) to provision the main traffic, it actually saves us from the hell.

during debug, we can just connect to low speed side band and control the whole high speed traffic, w/o painfully tracking the high speed inband traffic.

Answer 4

I'd like to offer a slightly different angle on this.

All modern digital interfaces are thought to transmit not only bulk massive amount of data, but also usually have provisions for configuration of the interface, receive various statuses, get interface capabilities, and send other controls like managing interface power on several levels of performance. All this is called "in-band" communication.

However, there are frequent (too frequent) cases when either an interface architect screws up a tiny bit of specifications, or design delivers buggy RTL for fix of which there is no time, or interface link partner have a misinterpretation of specs and have some corner case screwup, or some catch-up in global specifications happens due to changing market conditions (like change in main clock input). If in this case some part of protocol becomes broken, the solution usually is in using spare GPIO (general-purpose I/O) to work around the issue. These signals go outside the main channel, out-of band, and become "side-band" signals. In most cases these signals are never removed, due to huge cost of associated development, and the workaround becomes permanent.

When a document says "some implementations may choose to use", it simply means a covert form that there might be differences in multiple silicon revisions that might need a work-around.