Think of your digital components like a small network that lives on your circuit board. The common serial peripherals in digital systems can use point-to-point topology, where each node connects to another node directly. The other approach is a bus topology, which would be used in I2C, where a component is connected to a group of other components through a common set of conductors (PCB traces).
Point-to-point is normally only seen when you have a master host processor that connects to individual peripherals with a single bus, such as with a microcontroller and a set of external ASICs. These systems are most common, but more complex systems can use an alternative form of the point-to-point topology with multiple peripherals in a long chain. These systems include some important timing constraints when clocked from a single source, and the design must use the right components that can pass data between them over successive regions of a long point-to-point bus.
Types of Point-to-Point Serial Buses
Serial buses like SPI and I2C can be routed from a processor to a peripheral or group of peripherals in several ways. This can involved shared clocks or data streams, enabling/disabling specific peripherals on the bus, or passing data between peripherals such as in a tree topology.
Direct Routing on Multiple Buses
An example shown below illustrates how a master processor with multiple serial interfaces can be used to route directly to each peripheral. The other option to implement this would be to use a GPIO expander with specialty logic in your embedded application, or a serial buffer IC to expand the number of interfaces.
Two standard methods for connecting to peripherals with serial interfaces. Left: master has multiple interfaces; Right: master has one interface shared across all peripherals.
This is a simple approach taken in setting up point-to-point routing with multiple peripherals for a few important reasons:
As long as the source-synchronous clock is not paralleled, each peripheral has its own timing requirements
Peripherals do not need to be enabled or disabled individually
Logic operations can happen asynchronously
Alternative approaches are taken to reduce routing in the system, which normally means multiple peripherals share the same conductors in a bus topology. If you wanted to reduce routing by clocking all peripherals with a single clock, you technically could do this by paralleling the clock or by using a clock buffer IC.
Along each of the branches in the image above, we could have one of the peripherals sending data to another peripheral
Chaining in Point-to-Point
If you need to pass data to multiple peripherals, how would you do this easily? One way to do this is to pass data from one peripheral to the next while using the master’s CLK output as a system clock. As can be seen below, this would provide unidirectional communication down the bus to peripherals with a single timing scheme. This could be used on large systems that have multiple masters which must receive data from each other to operate successfully.
For this chaining to work, each downstream peripheral must be able to pass a command from its SDI to SDO pins during a single command cycle. This creates a propagation delay of one command cycle. This means that the CS or ENABLE pin on a peripheral must remain enabled for that extra command cycle, which will be equal to the total number of pulses in that cycle. If the ENABLE is toggled during this time, then the data is not passed to the peripheral’s SDO pin. This timing constraint must be written into the master’s logic in order to create this point-to-point chain.
This “chaining” technique can also be used with power, and in fact it is common to see power stages self-synchronize by using their PGOOD and ENABLE pins. This chaining technique does not involve sending data but it does involve connecting a cascade of power stages in the exact topology shown in this section. Read this article to learn more.
Will it Work in Parallel?
In short, yes the use of daisy-chaining in this way will also work in parallel as long as the timing constraints are obeyed across the bus. The typical bus where this would be implemented is on a parallel peripheral interface (PPI), although this is much less common today due to the prevalence of SPI. This could also be implemented as custom logic in an FPGA.
The timing constraints being enforced in a serial design would also be implemented in a parallel design. This is because the timing requirements, such as setup and hold time, are determined by the interface and not the topology. Timing analysis is also needed and minor adjustments on the trace routing might be needed if timing violations are present. This can be analyzed in a mixed signal circuit simulator in your front-end design and schematic capture tool.
Whenever you want to build and analyze digital or analog circuits, make sure you simulate your designs with the complete set of mixed-signal simulation features in PSpice from Cadence. PSpice users can access a powerful SPICE simulator as well as specialty design capabilities like model creation, graphing and analysis tools, and much more.