Silicon Labs
|
Silicon Labs Community Silicon Labs Community
  • Products
    1. 8-bit MCU
    2. 32-bit MCU
    3. Bluetooth
    4. Proprietary
    5. Wi-Fi
    6. Zigbee & Thread
    7. Z-Wave
    8. Interface
    9. Isolation
    10. Power
    11. Sensors
    12. Timing
  • Development Tools
    1. Simplicity Studio
    2. Third Party Tools
  • Expert's Corner
    1. Announcements
    2. Blog
    3. General Interest
    4. Projects
How to Buy
English
  • English
  • 简体中文
  • 日本語
//
Community // Blog

Official Blog of Silicon Labs

  • Show More
    Publish
    • Immediately
    • Draft
    • At scheduled date and time
     
      • Timing 201 #7: The Case of the Dueling PLLs – Part 1

        kgsmith | 11/324/2020 | 12:33 AM

        Introduction

        RF and microwave frequency synthesizers often employ multiple connected PLLs. These architectures trade off complexity in favor of improved phase noise, smaller frequency step size, and faster switching [1]. In timing applications we may also employ multiple PLLs to combine timing functions and/or shape phase noise.   

        For example, the white paper, “Optimizing Clock Synthesis in Small Cells and Heterogeneous Networks”, describes Silicon Labs’ DSPLL dual-loop architecture as used in the Si538x wireless jitter attenuators intended for small cell applications [2].  This particular approach is a nested dual-loop as opposed to a cascaded (concatenated) dual-loop. There are definite advantages to this implementation and some important considerations.

        One consideration is the necessary bandwidth relationship between the inner and outer loops. This topic leads to the play on words in the main title of this blog post, The Case of the Dueling PLLs.  A second consideration is the difference in how one analyzes the phase noise for such an architecture, which arises from the fundamental difference between these two approaches as explained below. 

        General Motivation for a Dual-Loop PLL Architecture

        As you may recall from a previous blog post, there are two basic PLL clock applications [3]:

        • Clock Generator (aka clock multiplier, frequency multiplier, etc.)
        • Jitter Attenuator (aka jitter cleaner)

        Low noise references are input to clock generators, which are usually wide bandwidth (e.g., 100s kHz to MHz). By contrast, jittery clocks are input to jitter attenuators, which are usually narrow bandwidth on the order of kHz or less.

        But what if your clock application requires both functions? The most straightforward approach is to cascade the two PLLs in series as discussed in the next section. 

        Cascaded Dual-Loop PLL Architecture

        The figure below, taken from the cited white paper, illustrates a single-chip, cascaded dual-loop architecture. (Note that this sense of the term cascade is different from classic control system terminology. Here we mean two PLLs concatenated or in series.)

        In this case, the left hand PLL1 with an analog Voltage Controlled Xtal Oscillator (VCXO) is used as a narrow band jitter attenuator stage.  The jitter attenuated clock signal is then input to the right hand PLL2, which is used as a wide band clock generator stage. The VCXO need not be very high in frequency but should have good close-in phase noise. This generally means a high Q crystal, which is why this component is typically external to the IC. This necessitates an external control voltage signal to the VCXO.

        The on-chip VCO needs to be high enough in frequency so that the divided down clock can yield the necessary output clock frequencies. It also should have low phase noise at high offset frequencies.

        This particular example is depicted as all analog with several external filter components and sensitive traces. However, there is no intrinsic reason why a cascaded dual-loop architecture could not be implemented more digitally and with filtering on-chip.

        Because the PLLs in the example above are in-series and independent, the total output phase noise can be calculated as a cascade of phase noise processing elements as described in [3].  

        Nested Dual-Loop PLL Architecture

        The figure below, also from the cited white paper, illustrates a nested dual-loop architecture. In classic control system terminology, this would actually be considered a variation of a cascade control system. For clarity, I will use the term nested here. Think of it as the PLL equivalent of nested Matryoshka dolls.

        In this case, the inner loop (IL) PLL is being used as the “VCO” or rather the Digitally Controlled Oscillator (DCO) of the outer loop (OL) PLL. This is the fundamental difference between these two approaches, which will determine how one calculates the total phase noise.

        How does this work?

        1. The output of the OL digital loop filter modulates the return path of the IL.
        2. The output of the IL VCO is in fact the fOUT in the diagram. In practice, this output frequency is divided further to yield the necessary output clocks.

        What are the advantages to this approach?

        In this particular pair of examples, we reduce the number of tuned oscillators from two (VCXO and VCO) down to one (XO and VCO). This eliminates the need for one of the loop filters (be it internal or external) and a sensitive voltage control line, which must otherwise be routed externally. This decrease in components makes for a more compact solution which reduces the overall PCB footprint.

        Could you implement a nested dual-loop with a VCXO?

        Yes, in principle. There is no intrinsic reason why you couldn’t implement a nested dual-loop architecture that also uses an external VCXO.  Such an approach might even make sense if a particular VCXO has better phase noise performance, perhaps at a higher frequency (update rate). However, you would lose the specific advantages discussed previously. This is why the Si538x wireless jitter attenuators do not support an external VCXO.

        What exactly is the Duel?

        In these types of nested feedback control loops, the inner loop must be faster than the outer loop. If the loop speeds are comparable, then the loops will contend or “duel” with each other.

        In PLL terms the inner loop must have a wider bandwidth than the outer loop.  This should make intuitive sense if you consider the relative difference in impact of inserting a really slow “DCO” into an otherwise fast PLL versus inserting a really fast “DCO” into an otherwise slow PLL. The former case significantly impacts the PLL and may even have stability or locking issues due to inserted additional delay. By contrast, the latter case is not impacted significantly. This tells us that the inner loop must be the faster (wider bandwidth) clock multiplier and the outer loop must be the slower (narrow bandwidth) jitter attenuator. Further, it tells us that at start-up and during the lock process, we want the inner loop PLL to stabilize and lock before the outer loop.

        Another way of thinking about this is to recall that PLLs function as a low pass filter for phase noise arising from any source in the loop, except when they function as a high pass filter to VCO phase noise. For the OL PLL to modulate the IL’s return path without attenuation, the signal must be well within the IL BW.  

        Incidentally, if you want to estimate one quantity from another, such as frequency step rise time from PLL bandwidth, you may use this relationship:

        Tr [10%-90%] * BW [3dB] ≈ 0.35

        See for example, Howard Johnson’s discussion in the article, PLL Response Time [5].  Per his article, the time bandwidth product varies from 0.35 to 0.38, depending on whether the PLL behaves closer to a single-pole or double-pole response.

        How much faster or wider bandwidth must the inner loop be?  In mechanical engineering and process control systems, the differences in nested loop speeds can be relatively small.  A mechanical IL may be 5x to 10x faster than a mechanical OL. See for example Danielle Collins’ servo loop article in [6].  However, in timing applications, the difference in bandwidths is typically much greater. Nested dual-loop IL BWs are typically on the order of MHz, whereas OL BWs can be on the order of 10 Hz to 1 kHz, so the ratio is closer to the IL being 1000x to 100,000x faster than the OL. 

        Note that for Si538x devices, the IL BW is wide (~ 1 MHz), fixed, and optimized.  Because it is so wide, there is no jitter attenuation at the device’s XO inputs, i.e., the XA/XB pins. Therefore, we should be careful that noise and interference does not couple into the device via the XO circuit at these pins. This is why we recommend low phase noise XOs to be placed as close as possible to the device so as to minimize PCB trace lengths.

        Can this idea be extended?

        Yes, in principle. The servo control loop article cited earlier discusses a servo motor control with three nested loops, inside to outside as follows: current feedback, velocity feedback, and position feedback. Similarly, you can “triple nest loop” clock PLLs to shape the phase noise to track select input clocks with different phase noise characteristics over different frequency offsets. However, this particular approach is not utilized by the Si538x devices.  

        Conclusion

        I hope you have enjoyed this Timing 201 article. In the Part 2 follow-up post, I will discuss in more detail how to calculate the phase noise of the nested dual-loop approach using a simplified example.

        As always, if you have topic suggestions or questions appropriate for this blog, please send them to kevin.smith@silabs.com with the words Timing 201 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.

        Cheers,
        Kevin

        References

        [1] W. F. Egan, Advanced Frequency Synthesis by Phase Lock. Wiley, 2011. See for example section 7.1 regarding the Two-Loop Synthesizer where two loops interact via a mixer.

        [2] Optimizing Clock Synthesis in Small Cells and Heterogeneous Networks
        https://www.silabs.com/documents/public/white-papers/Silicon-Labs-Next-Generation-DSPLL-Technology-White-Paper---June-2015.pdf

        [3] Timing 101 #11: The Case of the Noisy Source Clock Tree Part 1
        https://www.silabs.com/community/blog.entry.html/2018/10/30/timing_101_11_the-2uqO

        [4] Timing 101 #12: The Case of the Noisy Source Clock Tree Part 2
        https://www.silabs.com/community/blog.entry.html/2018/12/21/timing_101_12_the-ikzY

        [5] H. Johnson, PLL Response Time, High-Speed Digital Design Online Newsletter: Vol. 15 Issue 04,
        http://www.sigcon.com/Pubs/news/15_04.htm

        [6] D. Collins, Why is the bandwidth of a servo control loop important?, April 20, 2017, https://www.motioncontroltips.com/why-is-the-bandwidth-of-a-servo-control-loop-important/

      • Create and Prototype Fast with the BGM220 Explorer Kit

        Jackie Padgett | 11/314/2020 | 10:27 PM

        Developers interested in adding Bluetooth connectivity to their IoT designs now have a low-cost option for evaluating the recently announced BGM220P Wireless Gecko Bluetooth Module. Priced at just $9.99, the BGM220 Explorer Kit includes a USB interface, an on-board SEGGER J-Link debugger, one user-LED and button, and support for hardware add-on boards via the versatile mikroBus™ socket standard from MikroE and a Qwiic® connector from SparkFun. Both of these standards are engineered for simplicity and allow for open-source platform development. The hardware add-on support makes it possible for developers to create and prototype applications using an endless combination of off-the-shelf boards from mikroE, sparkfun, AdaFruit, and Seeed Studios. The BGM220P is optimized for wireless performance and is among the first Bluetooth modules to support Bluetooth Direction Finding while delivering up to ten-year battery life from a single coin cell.  

        The Explorer Kit was designed specifically with quick prototyping in mind so IoT developers can go from concept to creation quickly across a wide range of applications. This is a very fast, efficient way to experiment with the BGM220P Module, an ideal device for creating energy-friendly connected applications.

        Features at a Glance: 

        • User LED and push button
        • 20-pin 2.54 mm breakout pads
        • mikroBUS socket
        • Qwiic connector
        • SEGGER J-Link on-board debugger
        • Virtual COM port
        • Packet Trace Interface (PTI)
        • USB-powered

        You can purchase an Explorer Kit here and find out more about the BGM220 Bluetooth module here.

         

        Related Links

        https://www.mikroe.com/blog/silabs-click-shield

      • Eight Principles of IoT Security

        Jackie Padgett | 11/310/2020 | 05:49 PM

        There are many challenges facing embedded development engineers tasked with implementing effective security measures. Knowledge of what is being protected, the threat landscape, and specific attack vectors to be protected against is necessary. Not to mention the added urgency that comes with overreported, high-profile breaches.

        Securing embedded devices is no longer optional. As more products became connected, the primary perceived attack vectors originated from internet traffic, but now entire embedded systems are subject to constant and varied threats.

        There are several techniques that developers can employ to make the task of securing systems much easier. Silicon Labs is a founding member of the ioXt Alliance, an industry-led initiative that, with partner collaboration, has led to the creation of eight key principles.

        Click here to access the whitepaper.

        Principle 1 – No Universal Passwords

        Often, high-volume consumer devices are all shipped with the same default password. Typically, users want to deploy their new device quickly, so many do not take the simple step of changing the default password to a new one. Shipping each new device with a unique factory-programmed password is a simple first step in making it more difficult for adversaries to gain access to or take control of, potentially, hundreds of deployed devices.

        Principle 2 – Secured Interfaces

        Any microcontroller-based device has a multitude of interfaces and ports that can be accessed either locally or remotely. The primary application will use some of these ports during operation and for communications. However, the rest (particularly any that function as external communication interfaces) must be secured. Likewise, any IC-to-IC interfaces (e.g., between the microcontroller and a display controller) must be secured. It is recommended that all interfaces be encrypted and authenticated during use.

        Principle 3 – Proven Cryptography

        In a world of open and interoperable technologies, the use of industry-recognized, open, and proven cryptographic standards is essential. The use of closed, proprietary cryptographic algorithms is not recommended. The use of open cryptographic standards encourages participation by all developers, engineers and stakeholders so that they can be continually evaluated for potential vulnerabilities against new security threats.

        Principle 4 – Security by Default

        It is essential that when a consumer purchases a new device, it is already set for the highest possible levels of security. Shipping a product with no or minimal security options configured is liable to pave the way for adversaries to take advantage. The consumer out-of-box security experience should be that all possible security measures are enabled. Developers should not leave a consumer unprotected by default.

        Principle 5 – Signed Software Updates

        With the increasing number of consumer smart home devices that can update themselves automatically over the air being shipped, the priority is that every update should be signed cryptographically. In this way, hackers are prevented from attempting to update a device with malicious code.

        Principle 6 – Software Updates Applied Automatically

        Consumers shouldn't have to become administrators of their own devices, faced with the choice of whether or not to update a product's software image. If an update needs to be made, it should be deployed and implemented automatically. Moreover, updates should be applied at times when they will not compromise the device's operation. For example, a smart connected washing machine should not be updated while the machine is in use.

        Principle 7 – Vulnerability Reporting Scheme

        Often, consumers who experience a problem with their embedded smart home device are unsure who to contact. Has it been compromised? Is there a new vulnerability that should be reported? This principle pledges that product manufacturers will create a means for customers to report problems and communicate their concerns regarding product security.

        Principle 8 – Security Expiration Date

        As with product warranties, which have an expiration date after purchase, the period during which security updates are available should also be defined and communicated to the consumer. Continuing to support a product with security updates involves continued engineering costs, so consumers need to be able to make informed decisions at the time of purchase. Manufacturers also have the option to offer extended warranties to offset ongoing security updates.

        The detailed explanation of the way we embrace these principles can be found in the Silicon Labs – IoT Endpoint Security Fundamentals document.

        Security in the Smart Home

        We already have far more control over our homes than we could imagine a few years ago, thanks to the IoT, and that is not slowing down. This means preparing for the next generation of cyber criminals will be a challenge we solve as an industry. Our state-of-the-art Secure Vault, has been design to help connected device manufacturers address these evolving threats by protecting from unauthorized access and guaranteeing chip authenticity. Through over-the-air updates, Secure Vault strengthens product security, future proofing, and addresses security regulation without adding cost or complexity.

        Secure Vault features include:

        • Secure Device Identity certificate, similar to a birth certificate, for each individual silicon die, enabling post-deployment security, authenticity and attestation-based health checks, guaranteeing the authenticity of the chip for its lifetime.  
        • Advanced Tamper Detection that enables developers to set-up appropriate response actions when the device experiences of unexpected behaviors, such as extreme voltage, frequency, and temperature variations, which could indicate a vulnerability
        •  Secure Key Management and Storage, a central component to protect against direct access to an IoT device and its data by encrypting and isolating the keys from the application code and using a master key encryption key (KEK) generated from physically unclonable function (PUF) hardware

        To learn more about how cyber threats are evolving and how industry regelation is taking shape, check out our whitepaper, Preparing for Next-Generation Cyber Attacks on IoT.

      • Smart Buildings Webinar Recap: Constructing Wireless Infrastructure for the Future

        Jackie Padgett | 11/307/2020 | 06:14 PM

        We were so excited to join Omdia and Acuity Brands in co-hosting a webinar about the challenges and solutions facing developers in the smart buildings space. Our VP and GM of Industrial and Commercial IoT products, Ross Sabolcik, joined David Green from Omdia and Trevor Palmer from Acuity Brands to discuss challenges and solutions facing IoT developers and businesses in the smart buildings space. David facilitated the conversation, and his perspective as the senior research manager at Omdia with a focus on global energy demand invited lively conversation regarding the drivers influencing innovation in this area. While it likely doesn’t come as a surprise that long term savings, cutting energy usage, and improving security are key drivers in smart building deployment, how we’re getting there might not be what you expect.

        Smart Building Webinar

        Click here to watch the webinar replay.

        Focus on Energy Efficiency

        The energy-saving aspect is galvanizing commercial and residential applications alike, even though one is focused primarily on ROI, while the latter is more interested in user experience. Quantifying the energy efficiency of both is important. This means energy efficiency has graduated from a nice-to-have to an essential component of any smart building project. One of the ways we measure the progress of a smart building application is simply by looking at the number of connected pieces of equipment it utilizes. Generally speaking, this number is increasing by about 10 percent year-over-year and is expected to do so for the next two decades.

        And more than half of all new connected equipment falls squarely into the energy domain, including lighting and HVAC applications. These are areas where energy efficiency can be easily quantified, and like most smart device implementations, the more effectively you can demonstrate strong ROI, the faster the market will move towards adoption. An extension of being able to quantify energy savings through connectivity is bringing the same functionality to bear on business metrics, and making sure IT and OT are leveraging emerging technology. According to Omdia, adoption of smart building technology will grow at 10 percent every year through 2025 and beyond, and while energy monitoring is the single most important use case identified by building/facility managers, it’s not the end.

        Integration with Existing Infrastructure

        Another key theme was the ability to integrate new smart building technologies – particularly wireless technologies – into existing infrastructure. Facility managers are faced with the dual challenges of harnessing legacy equipment and technology to realize energy efficiency and improve the experience, but also to adopt tools and retrofit technologies that don’t require extensive reconstruction or building upgrades. Bridging this gap is one of the responsibilities that falls to the manufacturers serving this industry. On one hand it’s our responsibility to innovate in ways that allow customers or prospects to be successful with legacy infrastructure or the tools with which they are already comfortable with. We risk alienating the audience if we attempt to force-feed overly complicated technologies to realize gains. On the other hand, how effectively we can innovate on new solutions that can integrate with existing systems with minimal disruption will also be a key variable in adoption. Technology must make it easier to do these things, not harder.

        The majority of new applications are being retrofitted into existing systems, and this is a trend we see across multiple industries. From Silicon Labs’ perspective as an IC provider, it’s never been easier to retrofit wireless functionality into a wide variety of applications and systems. That wasn’t the case just a few years ago, when operators might have struggled just getting wireless technology to work, let alone implemented. Now the bigger challenge is creating the most effective use of connected smart building solutions to achieve strong ROI for the end user.

        A Holistic Approach to Smart Buildings

        Once you create a wireless network for lighting control, the possibilities for that network to deliver additional value add services multiply. Even if you have the right technical solution, you still need to get the most out of it. This is where hardware, connectivity, and software applications need to be considered as a system instead of its individual components. Like a chain, any network solution is only as strong as its weakest link, and vendors should think about how the overall system can contribute dramatically more than just making room temperature more comfortable. A lighting control system for example, can be imagined as a constellation of sensors for a connected building to bring smarter, more efficient operation to more than just lighting. In fact, the savings that can be realized through smart lighting can actually be used to fuel more ambitious applications aimed at solving business challenges. In a retail environment, for example, energy savings is important, but increasing sales or effectively managing customer traffic can have a direct impact on the bottom line.

        Traditionally, these problems would be beyond the domain expertise of lighting manufacturers, but more and more connectivity baked into lighting solutions is making it possible to address these issues. Leveraging Bluetooth mesh technology, for example, allows installers to easily go in and provision the network with their cell phone, without having to deal with cloud and gateway connectivity. The ease of installation allows customers to quickly get their buildings connected and consider adding on additional services beyond lighting, including location services and predictive maintenance.

        For more information about how connectivity is shaping the present and future of smart buildings, you can watch a reply of this webinar here or check out the latest in smart industry from Silicon Labs here.
         

         

      Tags

      • Wireless
      • High Performance Jitter Attenuators
      • EFR32FG22 Series 2 SoCs
      • EFR32MG21 Series 2 SoCs
      • Security
      • Bluegiga Legacy Modules
      • Zigbee SDK
      • ZigBee and Thread
      • EFR32BG13 Series 1 Modules
      • Internet Infrastructure
      • Sensors
      • Wireless Xpress BGX13
      • Blue Gecko Bluetooth Low Energy SoCs
      • Z-Wave
      • Micrium OS
      • Blog Posts
      • Low Jitter Clock Generators
      • Bluetooth Classic
      • Makers
      • Flex SDK
      • Tips and Tricks
      • timing
      • Smart Cities
      • Smart Homes
      • IoT Heroes
      • Reviews
      • RAIL
      • Simplicity Studio
      • Tiny Gecko
      • EFR32MG22 Series 2 SoCs
      • Mighty Gecko SoCs
      • Timing
      • Temperature Sensors
      • Blue Gecko Bluetooth Low Energy Modules
      • Ultra Low Jitter Clock Generators
      • General Purpose Clock Generators
      • EFR32BG22 Series 2 SoCs
      • Industry 4.0
      • Giant Gecko
      • 32-bit MCUs
      • Bluetooth Low Energy
      • 32-bit MCU SDK
      • Gecko
      • Microcontrollers
      • Jitter Attenuators
      • EFR32BG21 Series 2 SoCs
      • News and Events
      • Wi-Fi
      • Bluetooth SDK
      • Community Spotlight
      • Clock Generators
      • Biometric Sensors
      • General Purpose Jitter Attenuators
      • Giant Gecko S1
      • WF200
      • Flex Gecko
      • Internet of Things
      • 8-bit MCUs
      • Wireless Jitter Attenuators
      • Isolation
      • Powered Devices
      • Power

      Top Authors

      • Avatar image Siliconlabs
      • Avatar image Jackie Padgett
      • Avatar image Nari Shin
      • Avatar image lynchtron
      • Avatar image deirdrewalsh
      • Avatar image Lance Looper
      • Avatar image lethawicker

      Archives

      • 2016 March
      • 2016 April
      • 2016 May
      • 2016 June
      • 2016 July
      • 2016 August
      • 2016 September
      • 2016 October
      • 2016 November
      • 2016 December
      • 2017 January
      • 2017 February
      • 2017 March
      • 2017 April
      • 2017 May
      • 2017 June
      • 2017 July
      • 2017 August
      • 2017 September
      • 2017 October
      • 2017 November
      • 2017 December
      • 2018 January
      • 2018 February
      • 2018 March
      • 2018 April
      • 2018 May
      • 2018 June
      • 2018 July
      • 2018 August
      • 2018 September
      • 2018 October
      • 2018 November
      • 2018 December
      • 2019 January
      • 2019 February
      • 2019 March
      • 2019 April
      • 2019 May
      • 2019 June
      • 2019 July
      • 2019 August
      • 2019 September
      • 2019 October
      • 2019 November
      • 2019 December
      • 2020 January
      • 2020 February
      • 2020 March
      • 2020 April
      • 2020 May
      • 2020 June
      • 2020 July
      • 2020 August
      • 2020 September
      • 2020 October
      • 2020 November
      • 2020 December
      • 2021 January
      • 2021 February
      Silicon Labs
      Stay Connected With Us
      Plug into the latest on Silicon Labs products, including product releases and resources, documentation updates, PCN notifications, upcoming events, and more.
      • About Us
      • Careers
      • Community
      • Contact Us
      • Corporate Responsibility
      • Privacy and Terms
      • Press Room
      • Investor Relations
      • Site Feedback
      • Cookies
      Copyright © Silicon Laboratories. All rights reserved.
      粤ICP备15107361号
      Also of Interest:
      • Bring Your IoT Designs to Life with Smart,...
      • A Guide to IoT Protocols at Works With...
      • IoT Hero Rainus Enhances the In-Store Shopping...