Official Blog of Silicon Labs

      • Timing 101: The Case of the Split Termination

        Lance Looper | 11/333/2017 | 02:48 PM

        Welcome to another edition of the Timing 101 blog from Silicon Labs' Kevin Smith.

        As I write this post it is late November. Here in the US we celebrate Thanksgiving Day on the fourth Thursday of November each year. It is customary to celebrate with friends and family and to give thanks for ones blessings in general and over the past year.

        From a technical perspective, one of the things I am thankful for are the previous generations of engineers that laid the groundwork for our industry, and that trained, mentored, or otherwise gave opportunities to the current generation of engineers. Which reminds me of a particular topic...

        The Split Termination

        This month I would like to expand a little on a subject I first introduced in the Timing Knowledge Base article Terminating Differential Transmission Lines to Minimize CM Noise. That article described a relatively simple but very practical differential circuit termination suggested to me by an experienced EMI engineer many years ago. Think of it as a tip similar to the sort of thing found in QST’s old monthly “Hints & Kinks” column, now known as "Hints & Hacks."

        I had never run across it in school and had never seen it in print but I have since used it ubiquitously. This is the case of the split termination and is the subject of this month’s column. The idea in a nutshell is expressed in the figure below. The arrow is to suggest we should generally move from the left hand “textbook” termination to the right hand more practical termination.


        Many output clock formats such as CML, LVDS, and LVPECL are routed and terminated differentially. This is usually illustrated as a pair of single-ended nominal uncoupled 50 Ω transmission lines (one for each polarity) terminating in to an ideal 100 Ω resistor at the far end or receiver end of the circuit. This is depicted on the left hand side as the “Textbook” 100 Ω Differential Termination.

        However, consider what happens when driving both input transmission lines simultaneously with the same voltage signal as can happen with noise. This is the Common Mode (CM) case as opposed to the usual Differential Mode (DM) case. Since the voltage is the same on both sides of the 100 Ω termination resistor, there is no current flow. Therefore, the CM signal doesn’t “see” the termination resistor at all and the high impedance receiver will look like an open. (The CM transmission line impedance in this example is 50 Ω // 50 Ω = 25 Ω.) So from a CM perspective we have a “noisy” signal generator driving a 25 Ω transmission line in to an open which means CM noise will be reflected, likely many times.

        CM noise can arise from power supplies and crosstalk impacting both transmission lines similarly. Further, even if you don’t have a noisy board, CM noise can also arise from imbalanced transmission lines or skew which is very common, if you will pardon the pun.

        How could we terminate both DM and CM? The practical split termination on the right is a T-network attempt to do this requiring only 2 more components and AC-coupled access to GND. Note that this particular termination does not increase the DC loading on the driver.

        There are other approaches but these may require more components, more DC current draw, more matching, or possibly a bias voltage. (Incidentally, this differential split termination is not to be confused with LVPECL pullup and pull-down terminations which occasionally are referred to as “split” terminations also.)

        The split termination explicitly splits the load termination and enforces a practical AC GND at the center-tap. Now CM current will flow and the CM signal will “see” a matching impedance, over the frequencies of interest. The 49.9 Ω selection is the closest 1% value to nominal 50 Ω. By contrast, a signal driven differentially will not “see” the center-tap capacitor to GND.

        Application Details

        Intuition suggests correctly that the center-tap capacitor enforces the CM voltage to see a low impedance to GND. The value 0.1 μF is a good large value and can be adjusted if necessary. There are a couple of more quantitative approaches to sizing the capacitor.

        (1) Size the capacitor so as to hold the charge steady during a maximum expected Δt skew (reference).

        (2) Consider the termination as a CM noise low pass filter with the corner frequency calculated as follows:

        For example, if R = nominal 50 Ω and C = 0.1 μF then the corner frequency is ≈ 64 kHz which should generally be plenty low enough.

        A similar version of this termination is used in CAN (Controller Area Network) applications for this purpose, supplying a special SPLIT CM voltage bias instead of GND. For an example of this, see NXP Semiconductors' AN10211, TJA104 High-Speed CAN Transceiver

        As noted in the original KB article, many SOCs and FPGAs support internal differential terminations. However, they usually do not support CM termination or give pin access to support a center-tap. (The CAN transceiver example cited above is an exception.) Therefore, if CM noise is an issue, it is best to disable the internal termination if possible, and use a higher performance external differential split termination instead.


        This month I’ve provided a little more insight in to the differential split termination first described in a KB article. In this Thanksgiving season, I am grateful for these and other circuit tips I have received over the years.

        This submission will be posted too late to beat the holiday so a belated Happy Thanksgiving to you all! I hope you have enjoyed this Timing101 article. As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to with the words Timing 101 in the subject line. I will give them consideration and see if I can fit them in.

        Thanks for reading. Keep calm and clock on.



      • New Flex Gecko Wireless Solution Takes Low Power to New Extremes

        Lance Looper | 11/319/2017 | 04:47 PM

        We have some great news for customers looking to differentiate their low-power and long-range wireless devices using our proprietary wireless EFR32 Flex Gecko  family. Silicon Labs just released another proprietary wireless solution – the new Flex Gecko EFR32FG14, which achieves significant low power gains and offers many of the same peripheral capabilities found in our previous Flex Gecko solutions.

        The EFR32FG14 expands on the success of the EFR32FG1 products by offering remarkable low-power benefits with up to 48 percent sleep current reduction, and new flexibility to connect to more peripherals, such as VDAC and OpAmp support. The new solution maintains RF performance enhancements from previous solutions while offering similar Flash and RAM memory options and improved security features.

        As always, our first priority during our design process is to listen to what our customers need to say and strive to make improvements based on their feedback. This new Flex Gecko solution is no different, and our customers will immediately see the low-power and performance benefits. New improvements to the EFR32FG14 include enhanced 2.4 GHz RF performance, deep sleep data processing, improved security with a new true random number generator security management unit, and boosted Sub-GHz performance with improved 2/4 (G) FSK sensitivity.

        To simplify product spec comparisons, we specified the test conditions of our Flex Gecko products in our documentation materials as clearly as possible, with minimum and maximum values for key parameters, and also provided RAIL-based application code examples using the FM modes.

        With more than 250 million Silicon Labs proprietary wireless ICs shipped to date, the new Flex Gecko solution furthers our expertise and footprint in the proprietary wireless market. The wireless Flex Gecko portfolio supports sub-GHz and 2.4 GHz designs with a single chip, simplifying board development, inventory management, and time to market for our customers. Our new solution along with all of our Flex Gecko devices are footprint compatible with the Blue Gecko and Mighty Gecko devices, allowing customers to add multi-protocol support into their designs later with minimal changes. Ultimately, Flex Gecko provides a seamless migration path to multi-protocol applications requiring the addition of BLE, Zigbee or Thread.

        The EFR32FG14 product will be used for a wide variety of low-power and long-range communications devices, such as smart meters, electronic shelf tables, home automation, security systems, lighting controls, medical emergency devices, and agricultural applications.

        As the IoT market continues to explode, the popularity of proprietary wireless solutions increasingly grows as designers look to optimize the performance and cost of their products without being constrained by industry standard or alliance requirements. From a market standpoint, we understand how critical it is for our designers to design a highly optimized proprietary network, which can often make a product stand out from competing products with unique performance and feature differentiators.

        Despite the popularity of proprietary wireless solutions – building out the designs can sometimes be a challenge for designers as it requires a deep understanding of all aspects from the physical layer and regulatory requirements to the network layer and application layer. Our Simplicity Studio development software simplifies this process and helps Flex Gecko customers maximize their hardware while creating unique device innovations. Go here to learn more about our supporting software development kits.

      • Employee Spotlight – Pranav Kaundinya

        Lance Looper | 11/318/2017 | 03:24 PM

        Pranav Kaundinya has been a member of the Power and Isolation – Design team since September 2015. In his role as Design Engineer he’s involved in the entire pipeline of chip design, starting from NPI (new product introduction) to supporting applications and testing products after a launch.

        Kaundinya was born in India, but lived in New York for several years before returning to India for middle and high school. He attended MIT in Boston before interning at Silicon Labs in the summer of 2014. As an NCG (new college graduate), Kaundinya has continually demonstrated his organizational and technical skills. Principal Design Engineer, Alan Westick said of Kaundinya, “[He] has been productive on his own assignments, striking the right balance between using proven design approaches where possible while coming up with creative solutions where innovation is needed to meet the product requirements.”

        Kaundinya’s favorite thing about working at Silicon Labs is the people. He thinks Silicon Labs employees are “talented and friendly people to work with and learn from.” He said, “Even though we’re no longer a startup, we’re still a small company and run like a startup in many ways (e.g. Tyson comes to our happy hours).”

        When asked where he’d go if he could travel anywhere in the world, Kaundinya said he’d go hiking in Bhutan, “the happiest place in the world.” He added, “I think it would be a unique experience to visit one of the last places in the world that is relatively untouched by technology and globalization (TVs were banned in Bhutan until the early 2000s). It’s also really hard to visit.”

        Always up for a challenge – we like your style! We’re proud to have you on the Silicon Labs team. Keep up the great work!


      • Webinar: Expanding Device Capability with Multiprotocol Connectivity

        LeighPankonien | 11/312/2017 | 05:05 PM

        Title: Webinar: Expanding Device Capability with Multiprotocol Connectivity

        Date: December 13 & 14, 2017

        Duration: 1 hour

        Multiprotocol connectivity makes it easier to deliver proximity-based mobile experiences with Bluetooth beacons through connected lights and building automation systems. Consumers also gain the ability to commission, control, and monitor IoT devices operating in Zigbee® mesh networks directly over Bluetooth® with smartphone apps. Smartphone control of connected devices is achieved through a single multiprotocol SoC or module supporting Bluetooth with low energy functionality and Zigbee, eliminating the need for gateways or border routers to send or receive messages to the cloud. 

        In this webinar, we explore how multiprotocol wireless technology advances IoT connectivity for next generation applications that are easier to deploy, use, and update.

        Join our hour-long webinar and get your questions answered during our Live Q&A session at the end.



      • Introducing Dynamic Multiprotocol Software for Wireless Gecko SoCs

        Lance Looper | 11/310/2017 | 12:33 PM

        Today we’ve introduced multiprotocol wireless software to drive advanced functionality for next-gen IoT applications by making it possible to unlock key benefits of both the Zigbee and Bluetooth low energy protocols. One of the exciting things about this multiprotocol solution is that it makes additional functionality possible for IoT devices without the complexity and cost that comes with a two-chip architecture, reducing cost and size by up to 40 percent.

        Users can commission, update, control, and monitor Zigbee mesh networks over Bluetooth with smartphone apps and the software makes it easier to deploy indoor location-based services by extending Zigbee-based lighting systems with Bluetooth beacons.

        Smart lighting is one application that benefits because consumers can use their smartphone to simplify device setup. Added to this, commercial Zigbee systems can be updated via a Bluetooth smartphone or tablet. IoT products inside the home can connect to popular automation platforms and that support Zigbee while at the same time supporting connectivity to smartphones for simple setup, control, and monitoring. Smart Buildings will also be able to get in on the action. Building automation systems based on Zigbee can be extended, making it possible for employees to interact using Bluetooth enabled devices.

        For lighting in particular, multiprotocol connectivity is an area that is making it possible for manufacturers to distinguish themselves. Multiprotocol functionality makes it possible to simultaneously combine protocols like Zigbee with Bluetooth® on a single chip through intelligent time-slicing. Used together, a lamp can communicate with established Zigbee mesh-enabled devices while providing Bluetooth beaconing and smartphone-enabled light control. Hardware supporting multiprotocol and developer tool features to consider when selecting a platform for designing control and lighting systems are also examined. 

        Check out the whitepaper, “Enhancing Smart Lighting with 802.15.4 Mesh, Bluetooth, and Multiprotocol Connectivity.”

        Our dynamic multiprotocol software is driven by powerful wireless protocol stacks and an advanced radio scheduler running on Micrium OS. The software development kit (SDK) is available in Simplicity Studio and includes a connected lighting demo supported on selected Wireless Gecko starter kits and mobile app reference designs.





      • Design a Multiprotocol Device in 3 Hours

        Siliconlabs | 11/306/2017 | 08:30 AM


        Title: Design a Multiprotocol Device in 3 Hours

        Date: Tuesday-Thursday, December 5-7, 2017

        Time: 12:00 PM Central Standard Time

        Duration: 3-day workshop, for 1 hour each day

        With Silicon Labs' software and hardware, you can design a single product that supports multiple wireless connectivity protocols. During our 3-day online workshop, we will spend an hour each day developing a Bluetooth and Proprietary multiprotocol project with the new Thunderboard Sense 2.  

        Day 1 we will briefly discuss Silicon Labs’ Bluetooth stack and introduce Simplicity Studio. We will walkthrough developing a Bluetooth project using the GATT editor in Simplicity Studio.  By the end of the lab, we will use our Blue Gecko mobile phone app to modify the Thunderboard Sense’s RGB LEDs using the device’s GATT characteristics.

        Day 2 we will discuss Silicon Labs’ Flex SDK which allows the developer to implement their own proprietary wireless networks. We will walkthrough a lab using the Flex SDK’s RAIL library to transmit data across a proprietary network.  By the end of the lab, our goal is to update the RBG LEDs of multiple Thunderboards across a proprietary network.

        Day 3 we will discuss the Gecko Bootloader of the EFR32 chipset and how it’s architecture allows us to switch application images and wireless stacks.  Our final lab will combine the previous Bluetooth and Proprietary projects using the gecko bootloader. By the end we will be able to set the RGB LED values of a Thunderboard via Bluetooth then reboot it into a proprietary network to update surrounding devices on the network.

        Note: At least two Thunderboard Sense 2s are recommended to test a network on Days 2 and 3. However you can still walk through the labs using a single board.