Basics of SoC I/O design: Part 2 – Hot swap & other implementation issues - Embedded.com

Basics of SoC I/O design: Part 2 – Hot swap & other implementation issues

Having dealt in Part 1 with some of the basics of SoC I/O pin assignment, in this second part we will deal with a variety of implementation issues, including hot swap, threshold voltages, interrupts, pin assignments and Interfacing with the devices being operated at voltage other than SoC’s core voltage

Hot Swap
Systems like industrial and network equipment requires live insertion or hot swap to avoid long start-up operation or other down time related inconveniences. Hot Swap usually means that an electronic module can be removed and then reinserted into a system while the system remains under power. The assumption is that the removal of the module and reinsertion will cause no electrical harm to the system.

To deal with this scenario, the interconnecting IOs must have what is called hot swap capability. This basically means that IO pins must offer a high impedance drive mode even if the module is not powered.

Normal GPIOs generally come with a limitation that the voltage input on it cannot be greater than the Vdd of the device. This is due to the ESD diodes on the IOs which start conducting when the IOs are higher voltage than the Vdd, as discussed earlier.

Certain SOCs comes with special IOs which have an ability to Hot swap. These pins can connect to another system that is powered even when the device having the pins is not powered. The unpowered device can maintain a high impedance load to the external device while preventing itself from being powered through an IO pin’s protection diode

In designs that would have a requirement to be part of a plug and play arrangement and requires a hot swap, the system designer should consider the case while part selection. The number of these hot swappable IOs required is another consideration the designer would have to look into because hot swap capability is available only few IO lines in device due to design overhead to implement them.

Threshold voltages
Input threshold voltage for any pin is characterized as the minimum input voltage that will be considered as logic High and maximum input voltage that will be considered as Low. Though most of the digital devices have CMOS drive level now a days, there are still many devices available which have other output levels like LVTTL (Low Voltage Transistor to Transistor Logic).

To deal with such I/o level mismatches, systems need the use of some interface devices that have selectable input threshold. To avoid the use of such external level translators, one must consider selecting an SoC/Controller which has i/o input threshold compatible with other devices.

Some of the SOCs have IOs that have programmable threshold where user is not restricted to standard threshold voltages. Changing the threshold is nothing but changing the reference voltage to the hysteresis comparator. Based on this functionality these pins can now be considered as simple comparators. There might be cases in the design when this functionality can be helpful.

Interfacing at other than SoC core voltage
While designing any system, many a time embedded designers face the problem that one of the devices work on a 3.3V domain and the other works on the 5V and some time on some other non standard voltages as well. Now interfacing them so they can communicate becomes a concern in design. But there are some tricks by using the IOs redundant capabilities to achieve this.

Let us consider a case when one device (Device A) is working on a 5V supply and requires communicating with another device (Device B) that is working on a 3.3V supply. The setup is illustrated in Figure 7 below.

Now first device cannot drive the line using the 5V level due to the ESD protection diodes as discussed in first part of article. This is a case where we could employ level translators to interface the two voltage domains. But there can be a way to work around this problem by using the internal drive modes explained previously.

Open Drain Drives low mode can get the pin to go to 0v when its state is zero and High Z when it is 1. Now if we were to make a open drain drive low pin on the device powered to 5V and have it pulled up externally to a 3.3V supply what we achieve is the 5V device now signaling at a 3.3V level.

Figure 7: Interfacing two devices operating at different voltages

But one must keep two things in mind while using this solution:

1) If this pin is being used in bidirectional mode, pull up voltage must not be less than VIHmin of the receiving device. For example if device A has a higher operating voltage hand, its VIH can be about 2V and if pull voltage is 1.8V, input voltage may not be recognized as High though device B is trying to drive the line High.

2) There is a resistive pull up which effectively in series with the pin capacitance thus adding an RC time constant to the pins rise and fall time. Thus the pull up resistor causes a delay medium due to the RC network setup between the pull up resistor and the pin capacitance. This can cause longer rise/fall times on the signals on the pin.

Above mentioned method can be used in many systems as most of the SOCs support open drain drive modes. However, they may be challenges while using this method due to the constrains described. Also, open drain drive modes need the use of external resistance which challenges system integration.

The best way to deal with this problem is to have different set of input output pins connected to different supply voltages as shown in Figure 8 below.

Some of the SoCs have their IO pins divided into several groups and each group can be operated at a different supply voltage. They eliminate the need of external voltage translators saving the board space and system cost.

One of the examples is Cypress’s PSoC3 and PSoC5. These devices have concept of quadrant supplies where the IOs are separated in distinct 4 quadrants. Each quadrant can have independent IO supplies and all associated IOs will signal at this IO quadrant voltage.

Figure 8: Using separate supply for separate group of IOs
The solution mentioned above no doubt works well when there is need of four (4) supply voltages for large group of IOs. What if there are few IOs which need to operate at different voltage?

Some of the SoCs have hardware controlled VOH for the pins. This is generally to avoid the larger group to work at a particular voltage when only a few pins are needed to run at the voltage. In such pins, source of PMOS transistor can be connected to any drive voltage.

With controllable source voltage, programmable drive modes these pins can resemble as uncommitted NMOS transistor. A while ago, we were trying to implement an MDAC (Multiplying Digital to Analog Convertor) in a device which natively did not have any of those.

One may think why someone would talk about MDAC while talking about IOs. But, capability of IOs to have hardware controlled VOH helped in implementing MDAC in that device. Figure 9 below shows the implementation of an MDAC with the help of IOs.

Figure 9: Using programmable VOH capability of the pins to implement a building block of MDAC

In this implementation, PWM’s duty cycle define the digital code. IOs helped to chop the PWM output between Input voltage and analog ground to implement the multiplication between digital code and input signal. Sign could be controlled using the Mixer available inside the chip.

Interrupts
Interrupts on input pins are used in any system to deal with and external event that requires triggering a code execution outside normal execution sequence. In basic controller based systems, most of the events contribute towards interrupt through input pins.

In case of SOC based systemsthe different peripherals in the system could contribute to interrupts to the design. But one of the most used interrupt source is still the IOs. Dealing with interrupts can be a significant overhead in some SoCs if number of interrupt lines are many and can cause system’s performance to degrade extensively.

So, one must understand interrupt handling on input pins while selecting the controller if input pin interrupt is an reasonable part of the system design.

Some controllers like the traditional 8051 tends to have one dedicated interrupt just for IOs. This means that the code execution on occurrence of an interrupt on any IO would transfer control to a specific interrupt vector. This is useful since there is a dedicated vector for IO interrupts.

But to distinguish which IO generated the interrupt would require the designer to add extra code in the interrupt to mask the inputs. However, it may be enough for some systems where interrupt is enabled only of very few lines or latency in servicing the interrupt is not a criterion of system performance.

Most controllers today tend to have a interrupt controller unit dedicated for the IOs. This architecture allows having a dedicated interrupt vector for each pin port. This is helpful since the interrupts are already vectored according to the ports from which they were generated.

The distinction in code needs to only mask the pins if required. In some applications, even there may be a need to resolve interrupt per pin and have a dedicated interrupt service subroutine for each of those.

So, to deal with such situation, some devices have capability of routing the pins to other digital peripherals and use their interrupt vectors.

There is another importance point to be taken care when it comes to interrupt on IO pins. Based upon requirement, one may need an interrupt to be triggered on rising edge or falling edge or on level.

There may be multiple requirements in the same system as well. Some of the devices available in market have capability to select interrupt type on pin basis. System designer must check these capabilities if needed in system.

Pin Assignments
We have seen about how IOs in today’s SOCs and controllers can be a mix of multiple functionalities. Where on the one hand SoCs empower user to integrate extensive features in single chip and encapsulate a gigantic system into a very small form factor, on the another hand they enforce user to bear some points in mind while assigning the pins for different functionalities.

Sometimes some IOs are configured as analog IOs where as others are just digital interfaces. Some are high current drives while others are high precision inputs. Hence to extract most out of the features of configurability and adaptability of these IOs, the design should take at most care in pin selection and placement.

Consider a case of an application that was having an analog precision temperature sensor connected to an SOC’s analog input. If the same device was to drive a PWM that in turn drives an actuator like an LED or motor driver, then the effect of the PWM on the analog input has to be taken care of.

Care must be taken in such cases to ensure that the analog input is placed at the most farthest IO from the PWM. The farther these interfering IOs are the lesser the cross talk they would see and thus reducing the noise seen in the analog measurements.

Sometimes adding a ground trace on either side of a sensitive signal helps in reducing its susceptibility to noise. On a similar note, adding grounded IO pins on either side of a sensitive signal line can also shield it well against a pin to pin coupled noise.

As discussed earlier, there are devices which have separate supplies to offer a distinct operating voltage per IO group. Apart from serving the purpose of just having separate operating voltage, these type of IO architecture could also serve the purpose of better isolation between signals.

The sensitive analog signals could all be populated in a specific group while the other digital and drive signals could be on other group supplies. This effectively avoids any kind of power supply or ground noise that could have coupled through.

Conclusion
There are extensive specifications and features which an IO pin posses and the architecture of the IO block in SoCs/controllers has evolved with technology. IO pins available in advanced devices have capability of selecting a particular drive mode based upon the external entity device is talking to.

Selectable slew rates let user decide if they want to deal with EMI issues externally or want to control them on pin level itself. Pins have ESD protection diodes protects to protect the device from electrostatic discharge but impose a lot of changes while dealing with issues relating to hot plug and play and interfacing the devices operating at higher voltages.

Some IO architectures have IOs divided in to multiple groups so that they can be powered at different voltages. Where, some of the devices have this capability even on pin level. Overhead while IO interrupts can ruin system’s performance.

Some of the SoCs available in market have capability of resolving IO interrupt on pin basis. Embedded designers must understand the capabilities of IO and how the appropriate usage of them can make system compact, cost effective and efficient in terms of speed.

To read Part 1 . go to: “The building blocks.

Sachin Gupta is a Senior Applications Engineer Sr. Cypress Semiconductor. He enjoys working on different mixed signal applications. He can be reached at sgup@cypress.com.

Kannan Sadasivam is a Staff Applications Engineer with Cypress Semiconductor Corp. He has spent a considerable amount of his past career designing and integrating Satellite subsystems. He loves working on different types of analog circuits and applications. He can be reached at qvs@cypress.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.