Current hot-swap controllers are great at what they do: simple yet reliable monitoring of critical load conditions and currents preventing power spikes that would otherwise damage either the backplane that the hot-swap board is plugged into or the hot-swap board itself. The drawbacks with the current hot-swap solutions, however, are that they're expensive and single, fixed-function solutions.
Additionally, the lack of flexibility in this portion of the system prevents systems engineers from discovering new methods of reducing or smartly managing the power consumption in these systems-let alone the potential cost savings that a new hot-swap controller solution may offer. This article will introduce how using a programmable approach can enable the next generation of reliable and programmable hot-swap controller systems to not only implement these critical tasks but also enable engineers to add more functionality and specifically customize implementations to their applications.
Why Hot-Swap Control Is So Critical
In describing the criticality of a hot-swap controller, let's first establish the jargon used in this article up front. First, the backplane is the chassis or the main board in the system to which hot-swap boards will be plugged into. The hot-swap board is the line-card or board that is designed to be inserted or removed without affecting the backplane (i.e. without having to power down or otherwise notify the backplane that you are inserting or removing the hot-swap board, think USB peripherals).
Hot-swap control has three main functions: 1) protect the backplane from any sudden drop in voltage that would affect the overall system or other hot-swap boards connected to the system; 2) prevent spikes in loads from one hot-swap board from affecting any other portions of the backplane or other host-swap boards connected; and 3) by all means necessary, provide a breaker circuit function in the event a hot-swap board inserted into the backplane contains a short-circuit or other system failure that could severely affect the overall system. Systems that employ hot-swap designs do so because of the requirement for reliability and redundancy and so all means available must be employed to maintain the reliability of these systems.
One might ask, if reliability is the utmost priority in these systems, why complicate them with a programmable implementation. After all, programmable approaches are inherently unreliable in that an engineer could inadvertently change how the device functions. The answer is both yes and no, given that programmability done right can be reliable. For example, Cypress enables a hot-swap controller solution via their software tool PSoC Creator by means of a tested and hardened packaged set of IP comprising a set configuration of the analog and digital building blocks of their PSoC Programmable System-On-Chip device (refer to Cypress AN64350). Additionally, a programmable architecture that is based on analog and digital peripherals, like the PSoC Programmable System-On-Chip, can implement the hot-swap controller without any reliance on any integrated indeterministic processor functionality (aka MCU) if the processor can enable a highly reliable approach on par with fixed-function alternatives.
Let's take a look at a quick comparison of a programmable solution versus a discrete, fixed-function device. In this case we will take a standard and popular -48V hot-swap controller, a Linear Tech LTC4261, and a Cypress PSoC Programmable System-On-Chip CY8C3866PVI-021ES2 configured as a hot-swap controller per the Cypress application note AN64350. The two examples we'll look at is both the in-rush current limiting function (the first critical main function described above) and the over-current protection function (the second critical main function). Before we get started, let's examine the test setup.
Both devices are connected to a simulated hot-swap board that essentially looks like a 24-ohm, 1,000 micro-farad load. The simulated backplane is the -48V power supply source. For the over-current test, a switch in the system will simulate a change in resistance of the system from 24-ohms to 6-ohms to force a spike in current in the system.
In this first example, the objective of an in-rush current limiting function is to control the initial ramp of current drawn to a maximum level and then ensure that the system, at some defined point, backs down to a normal operating level of current consumption. The ideal graph for this type of function is show below in Figure 1.
The LTC4261 is configured to limit the inrush current to a maximum of 2A (or 16mV when measured across a sense resistor in the system). The results are shown in Figure 2. From the oscilloscope graph, you can see the behavior of the power in the system. The blue line in this figure shows the current in the system (actually the voltage across the sense resistor configured such that 1A is equivalent to 8mV). The LTC4261 example limits the inrush of current to 3.4A, approximately 1.4A higher than the desired maximum-hopefully the system was designed with some headroom. The PSoC is configured to limit the inrush current to a maximum of 3A (or 24mV). The results are shown in Figure 3. From the oscilloscope graph, the blue line in this figure clearly shows more precise control of the inrush current roughly matching that of the ideal drawing (figure 1). In the end, the PSoC example limits the inrush of current to 2.8A (or 22.2mV).