|
In microelectronics, a crossbar is a type of interconnect topology commonly used in microcontroller designs employing an on-chip bus or standardised communication protocol.
First, a bit of background: In a "System-on-chip" design, all functional modules communicate via an on-chip bus. In terms of their bus interaction, modules can be classified as:
In a typical "System-on-chip" design there are several masters and slaves, all connected together by the on-chip bus. A typical bus master might be a CPU, DMA engine or DSP module. These all initiate transactions such as instruction fetches or data transfers. A typical slave module might be a UART or a timer.
Let's get back to interconnect and the crossbar: Consider a simple example, where we have two modules acting as masters, ("M1" & "M2") and two acting as slaves, ("S1"& "S2"). Both bus masters can access either slave. Consider these simple scenarios:
- M1 attempts to access S1 - With no other master or slave activity, S1 repsonds to M1's request, (a read or write), and the transaction is completed.
- Both M1 and M2 attempt to access the same slave, (S1), at the same time - We now potentially have a bus contention, since S1 can only respond to one request at a time. A bus arbiter must be used to resolve this situation. In this case, perhaps the aribter is programmed such that bus master M1 gets priority over M2: M1's transaction request is dealt with first. Our simple interconnect is no longer just a set of wire: It has functionality!
- M1 attempts to access S2 at the same time as M2 attempts to access S1 - If an arbiter is being used to control bus transaction, then M1, say, will have priority over M2 and will dealt with first. If , on the other hand, the simple arbiter is replaced with a crossbar, then the simultaneous requests from M1 and M2 can be satisfied concurrently, since they are addressing seperate slaves.
Bottom line: A crossbar is a multi-pathed network switch. It increases system bandwidth at the expense of added complexity. | 
