Next-Generation Hot-Swap Controllers

Transcription

1 Next-Generation Hot-Swap Controllers By Jim Davis, Product Mktg Engineer Staff, Cypress Semiconductor Corp. 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 hotswap board itself. The drawbacks with the current hot-swap solutions, however, are that they re expensive and single, fixedfunction 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 fixedfunction 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 AN 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. Hot-swap controllers: A programmable approach Page 1 of 6

2 Figure 1 - Ideal In-Rush Current Limiting 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). Figure 2 - LTC4261 In-Rush Current Limiting Hot-swap controllers: A programmable approach Page 2 of 6

3 Figure 3 - PSoC In-Rush Current Limiting In this second example, the objective of the over-current protection is to detect and limit the amount of current drawn by the hot-swap board for a set amount of time and, if necessary, shut down the hot-swap board to protect the backplane. The ideal graph for this type of function is shown below in Figure 4. For this example, both the LTC4261 and PSoC solutions are configured to limit the maximum over-current to 6.25A (50mV) for a maximum of 500µs (PSoC) or 512µs (LTC4261). The resulting oscilloscope captures for the two solutions are shown below (LTC4261: Figure 5; PSoC: Figure 6). From the graphs you can see that both approaches perform fairly well during this test; however, the PSoC solution still outperforms the discrete architecture. The LTC4261 limits the over-current level to a maximum of 7A (56.0mV) and successfully, after 512µs, shuts the system down. The PSoC solution limits the over-current level to a maximum of 6.3A (50.4mV) and also successfully shuts the system down after 500µs. The blue lines in these oscilloscope captures again represent the current in the system (via the voltage across a current sense resistor, 1A=8mV). Figure 4 - Ideal Over-Current Limiting Hot-swap controllers: A programmable approach Page 3 of 6

4 Figure 5 - LTC4261 Over-Current Limiting Figure 6 - PSoC Over-Current Limiting Extending the Capability of a Hot-Swap Controller with Programmability As seen from the previous section, a programmable solution can be configured to not only be as reliable, but also can improve the performance of a hot-swap controller function in a system versus discrete, fixed-function devices. The true benefit of a programmable approach, however, just starts here. The additional benefits of a programmable hot-swap controller such as that offered by Cypress s PSoC Programmable System-on-Chip, includes 1) the ability to customize the hot-swap controller specifically to the system s requirements versus requiring the system to comply to the device; 2) enabling additional errorchecking such as detecting whether required external components like the power-controlling FET and sense resistors are installed and working; 3) adding additional, disparate functions not normally found in the primary power domains of hot-swap controllers like thermal management functions, additional customized communications interfaces like PMBus to the backplane or hot-swap board s host application processors; and 4) there are many other customizations a design engineer can add as well because we re implementing the functionality with a programmable architecture. Hot-swap controllers: A programmable approach Page 4 of 6

5 With a discrete, fixed-function hot-swap controller, you must design your system to comply within its parameters such as designing the hot-swap board and backplane to operate within the hot-swap controller s ability to limit the inrush current, overcurrent, and breaker currents. With a programmable architecture, you simply set the current limits that your system is designed to operate within. For example, Cypress s hot-swap controller design using its PSoC Programmable System-On- Chip devices are configured via their software tool PSoC Creator with a graphical customizer (figure 7) which allows you to easily configure these parameters. Figure 7 - Cypress PSoC Creator Hot-Swap Controller Customizer In addition to simply customizing the parameters of a hot-swap controller, programmable approaches also enable additional functionality to provide in-system board check-out s and error-checking to ensure required external components are installed and operational. For example, the Cypress Application Note AN64350, a PSoC-based hot-swap controller solution, includes functionality to ensure the power-controlling FET, which limits the flow of power into the hot-swap board, as well as the current sense resistor circuitry, required to measure the current draw of the hot-swap board, are not only installed but operating within system limits. Should this functionality not meet requirements, the programmable architecture prevents power from flowing to the hot-swap board which would otherwise cause a catastrophic failure on the backplane and hot-swap board. Finally, the ultimate benefit that a programmable hot-swap controller offers is the ability to add functionality that either compliments the primary power domain management of the hot-swap board or completely disparate functionality that a system engineer would not normally think about. For example, many systems include hot-swap fan trays to provide cooling management and operational functions to a system. With the right programmable architecture, a designer could easily implement not only the hot-swap controller functionality of the system but also add fan or thermal management controls to the same device. With a PSoC device, for example, an engineer simply has to add the hot-swap controller IP to their design and then add the closed-loop fan controller IP to generate an all-in-one hot-swap fan tray controller solution this could be a reduction in components on this board from as many as four relatively high cost devices into a single chip solution. Additionally, with a programmable approach, you can add other functionality like I2C or PMBus interfaces to other processors to report current and voltage usage of the primary power rail so higher-level decisions can be made in the system such as shutting down blades in the system to dynamically reduce overall power consumption. In this article we reviewed the criticality of hot-swap controllers, how programmability done right can be reliable and how programmability greatly extends the capability of the hot-swap control function within a single-device. With the growing need to not only reduce cost but increase reliability and integration of components within systems like these, programmable architectures like Cypress s PSoC Programmable System-On-Chip are enabling the next-generation of hot-swap controllers. Hot-swap controllers: A programmable approach Page 5 of 6

6 Cypress Semiconductor 198 Champion Court San Jose, CA Phone: Fax: Cypress Semiconductor Corporation, The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. PSoC Designer, Programmable System-on-Chip, and PSoC Express are trademarks and PSoC is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective corporations. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement. Hot-swap controllers: A programmable approach Page 6 of 6