Earlier this month, UK-based RS Components announced the UrsaLeo Pi development kit, aimed at making IoT projects more accessible by combining our Thunderboard Sense 2 and a Raspberry Pi development board. Eric Brown over at Technologic Systems had this to say about the new development kit:
UrsaLeo’s kit, which was recently introduced by Mouser under its original “UrsaLeo UL-RPI1S2R2” name, is designed to send sensor input to Google Cloud for storage and analytics. The kit is designed for Industry 4.0, automotive diagnostics, healthcare, and general data monitoring.
The UrsaLeo Pi offers the same Silicon Labs Thunderboard Sense 2 sensor board found on UrsaLeo’s earlier UrsaLeo UrsaCloud UltraLite, also called the UrsaLeo UltraLite or UL-NXP1S2R2. While the UltraLite kit combines the Thunderboard 2 with NXP’s official development board for its Cortex-A7 based iMX6 UltraLite (UL) SoC, the UrsaLeo Pi uses a more powerful Raspberry Pi 3 SBC.
The UltraLite version offers more better debugging functionality than the Pi, as well as reduced “restrictions on hardware re-use,” says RS Components. However, the Pi version is faster and much cheaper. It costs 154 Pounds ($197) without VAT at RS Components compared to 455 Pounds ($582) for the UltraLite. Mouser’s prices are $195 and $550, respectively.
The Thunderboard Sensor 2 (or Thunderboard 2) board provides temperature, humidity, UV, ambient light, barometric pressure, indoor air quality, and gas sensors. You also get a 6-axis inertial sensor, a digital microphone, and a Hall sensor. The board is equipped with Silicon Labs’ EFR32 Mighty Gecko multi-protocol radio, which supports 2.4GHz wireless technologies such as Bluetooth Low Energy (BLE), Thread, ZigBee, or proprietary short-range protocols.
The kit is pre-loaded with an OTA-updatable Linux stack based on Yocto Project code. It automatically links up to a pre-registered Google Cloud account. Up to 50MB of data per month can be sent to the cloud platform free of charge.
A customizable dashboard “allows users to view sensor data and launch IoT applications such as storage and analytics,” says RS Components. The dashboard, which can be shared with third parties, is said to streamline the addition of new sensors and support user-definable events to trigger alerts.
Sample applications and APIs are provided to manage sensors, run diagnostics, and share information with enterprise or business intelligence applications.
In this post, The Case of the Noisy Source Clock Tree Part 1, we will go a step beyond the prototypical or “canonical” clock tree. I will discuss the motivation for adding a jitter attenuator and its impact on clock tree jitter estimation. So let’s get started.
The Canonical Clock Tree
The board level clock tree or clock distribution network, for say a data center application, is typically depicted with a crystal or low jitter XO (crystal oscillator) connected to a clock generator followed by one or more buffers, something like the following. This is what I refer to as the canonical clock tree:
The root or source of the clock tree in this example is a low jitter XO which determines the frequency stability of the clock tree overall. The clock generator then scales the input frequency from the XO to several different (usually higher) output frequencies. Finally, the clock buffer takes one of these output frequencies and yields multiple output clocks with the same frequency. The colored arrows in the figure are meant to suggest different clock frequencies.
We can estimate the total or end clock phase jitter of the canonical clock tree by applying the RSS or Root Sum of the Squares of the individual contributions. (This is the same summation in quadrature math used in cascaded statistical analysis of mechanical tolerances and other errors or uncertainties.)
For the example above, we can estimate the total RMS phase jitter as
Note that several prerequisites must hold true for this calculation to be valid:
Jitter Transfer versus Jitter Generation versus Additive Jitter
The last statement above means that the bandwidth of the clock generator is wide enough compared to the input clock phase noise that we need not consider the clock generator’s jitter transfer. You may recall that jitter transfer or jitter attenuation measures output clock jitter versus input clock jitter. This is often written as the Jitter Transfer Function or JTF. A PLL’s JTF acts as a low pass filter to input jitter and is a function of PLL bandwidth.
Jitter generation refers to the intrinsic jitter of a device. In the case of a clock generator, it is a measure of the output jitter when an ideal (no jitter) input clock is applied. A PLL-based clock device, even with a perfect input clock applied, still has PFD (Phase Frequency Detector) path noise and an intrinsic phase noise source, the VCO. Thus the need for a jitter generation term.
By contrast, clock buffers consisting only of amplifiers and perhaps dividers will always contribute additional noise to any input clock. Hence the use of the term additive jitter.
The Noisy Source Case
The example canonical clock tree above assumes a low noise clock as in a typical application. However not all clock trees have a low noise clock source.
What categorizes a source clock as relatively low or high noise? Let’s ignore the follow-on clock buffer for now and just compare the XO’s jitter generation versus the clock generator’s jitter generation. If they were exactly the same, the total jitter would increase by a factor of SQRT(2) or 41% which is substantial. If we choose the usual engineering convention of a 10% increase denoting significance, then we can back out that the XO’s phase jitter should be < 46% of the clock generator’s phase jitter. In other words, the source jitter must approach approximately half the clock generator’s jitter to significantly increase the output clock jitter.
A noisy (jittery) clock could be a recovered clock from serial data or derived from an FPGA. Perhaps the board itself is introducing power supply noise in to the XO. Such a clock tree then behaves as indicated in the figure below. The waveforms are shown thicker here than in the previous figure to suggest higher jitter.
We can still apply the RSS estimate even for a noisy source clock. However, often the resulting jitter will be too high for a typical clock distribution application. So what is our recourse?
Jitter Attenuator to the Rescue
In such applications, we need to add a jitter attenuator to clean up the source clock noise and improve the clock tree jitter performance. The figure below illustrates the basic idea where we have inserted a jitter attenuator between the noisy FPGA-derived source clock and the clock generator. Post jitter attenuator, the rest of the clock tree now looks like the canonical case. Note that in practical applications, a single device often performs both the jitter attenuator and clock generator scaling functions.
Like the clock generator, the jitter attenuator is a PLL-based device whose JTF acts as a low pass filter to input jitter. However, unlike the clock generator, the jitter attenuator is a relatively narrow bandwidth device versus the input clock phase noise. This violates one of the prerequisites for using the RSS estimate method. So, what is the best approach to calculate the expected phase jitter of the jitter attenuator output clock, and by extension the total or end clock jitter?
Clock Tree as a Phase Noise Processing System
In engineering, we usually analyze and measure the performance of systems in the frequency domain. Clock distribution networks aka clock trees are no different. The primary attribute of a clock is its frequency and the RMS phase jitter quantities are integrated from phase noise data. It should come as no surprise then that the better and more rigorous way to analyze clock trees generally is in the frequency domain.
In fact, following the clock signal from the source through jitter attenuators, clock generators or multipliers, and buffers, to the sink or destination is best viewed as a system that processes phase noise (this is an example of “one man’s noise is another man’s signal”).
The application of jitter attenuators in particular can really only be well understood by working in the frequency domain. The JTF can be modeled simply by the PLL bandwidth and expected attenuation in the jitter bandwidth of interest. At each phase noise offset frequency f we calculate the output clock phase noise in terms of the input clock phase noise, shaped by the JTF, and added in quadrature to the jitter generation phase noise contribution. We can then check to see if the resulting integrated phase jitter meets the required jitter performance.
I will discuss in more detail exactly how to do this and provide a measurement and spreadsheet example in the next post, The Case of the Noisy Source Clock Tree Part 2.
I hope you have enjoyed this Timing 101 article and will look forward to the follow-up.
As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to email@example.com 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.
Some circuits may be damaged if they try to talk to each other, and digital isolators are devices that make it possible for them to communicate without blowing each other up. In this Q&A, Silicon Labs’ Rudye McGlothlin answers a few questions about these devices and techniques for balancing safety and performance.
What is driving the Industrial market to use isolation components in the first place?
There are many needs that drive the use of isolation components. System requirements for component protection, user safety, signal level shifting, and adherence to safety regulations are primary drivers. In all cases the isolation components add value to the system by enabling additional functionality and ensuring safe operation of the system.
When I add isolation devices, what affects does that have on my circuitry?
Improved performance in many cases and, in all cases, additional component safety is achieved. Isolation devices allow for multiple power domains to coexist and communicate, which means that sensitive circuits are protected from switching circuits. Modern, digital isolation allows for massive integration, which means that circuit component count can decrease. Performance, efficiency, size, and cost are all things that can be affected when adding isolation devices.
What are my options when considering isolation components for my application?
Up until the last ten years, designers used optocouplers for their isolation needs, but digital isolation has come a long way since that time. Now, digital, CMOS-based isolation is the technology of choice for isolation tasks in the system.
What is the difference between an optocoupler and a digital isolation device?
Simply put, an optocoupler is a hybrid device that uses LED light to transmit data across an isolation barrier to a light detector. The LED turns on for logic High and off for logic Low. Optocouplers consume high levels of power, are prone to aging and temperature effects, and provide limited data rates, often below 1Mbps.
Digital isolation devices, on the other hand, were created to meet safety regulations while maximizing the benefits of modern CMOS technology. To do this, digital isolation devices use semiconductor process technology to create either transformers, or capacitors to transfer data instead of light. With this technology, performance and feature integration are both improved.
What is the best advice to give someone who is hesitant to make the switch from optocouplers to digital isolators?
Optocouplers, although incorporated in many designs, are based on outdated LED-technology that provides significant output variation over input current, temperature, and age. This reduces performance over the device’s lifetime. Digital isolation components easily provide multichannel isolation solutions with a much smaller footprint, increases system reliability due to a lower failure rate, offer twice the electrical noise immunity, operate over a wider temperature range (-40oC to 125oC), and do not age or degrade over time. In general, the use of a high-frequency carrier instead of light enables low operating power and high-speed operation, which allows for precise timing specifications.
I’m convinced, now what factors go into selecting a particular digital isolator for my application?
Feature set and isolation performance are both factors to consider with selecting a digital isolator. On the feature set side, consider the number of isolation channels and the channel configurations. Timing specifications, such as propagation delay, should be appropriate for your system. On the isolation performance side, it is important to gain an understanding of the isolation rating your system needs. Transient noise immunity, and electromagnetic emission profile are other considerations related to the isolation structure. With the isolation rating, there maybe be package options to consider given the system environment.
What is the biggest challenge a designer has after they’ve decided to make the switch?
The first challenge is to select the correct digital isolator for each application. As mentioned before, each component has its own specifications just as each application has particular needs. Once an appropriate device is identified and designed in, the system designer can proceed with their system evaluation in their typical fashion.
What safety requirements do I have to consider for my application?
Once you’ve nailed down your application’s needs, you’ll want to be sure that the devices meet appropriate Safety Standards as required by end safety agencies such as UL, CSA, VDE, and CQC. These safety agencies use their component safety standards to qualify and either specify a safety component’s one-minute voltage withstand rating, which is typically 2.5 kVrms, 3.75kVrms, or 5 kVrms, or its life-time working voltage, which is typically between 125 Vrms to 1000 Vrms. All of Silicon Labs’ component safety certificates can be requested online at silabs.com.
What is the typical life expectancy of a digital isolator’s isolation barrier?
This depends on the material used as well as its thickness. Standard materials used include polymer-based, polyimide-based, or SiO2-based insulators. In general, though, the life span of the barrier can easily be over 25 years.
What are some of the standard rated voltages I can expect to find?
Depending on the device manufacturer, common one-minute rated voltages are 1 kVrms, 2.5 kVrms, 3.75 kVrms, or 5 kVrms. For surge protection, some devices can reach 10 kVpk.
What creepage and clearance do your products support?
The two most common creepage and clearance requirements that are required by end systems for basic and reinforced insulation needing up to 250Vrms working insulation are 3.2mm and 6.4 mm respectively. In general, Silicon Labs’ narrow body SOIC packages support ~4mm of creepage/clearance and the wide body SOIC packages support ~8mm.
For more information about our digital isolation products, visit https://www.silabs.com/products/isolation/digital-isolators.
Csongor Meszaros joined the Silicon Labs Budapest team in April 2015 as an Applications Engineer and is currently the Applications Engineering Manager of Power over Ethernet (PoE) Products. In his role, he is responsible for new product validations, worldwide customer support, and evaluation board design. His team establishes a link between the integrated circuits (IC) design team, marketing team, and customers to help ensure new products meet customer expectations.
Csongor said he is tasked with solving at least one new customer issue nearly every day. Because a single issue can lead to a chain reaction, he and his team must work quickly to resolve any issues that arise. When Csongor is not problem solving, he works on widening our evaluation board (EVB) portfolio, which he said is “a very interesting and challenging responsibility, as it is always nice to compete with the competition, be creative, and provide high quality customer support.”
Csongor enjoys working in the Budapest office because he is surrounded by smart, kind colleagues. While it can be challenging to work in a different location than the company headquarters, he said, “Ensuring strong and concise communication between all members of the teams is essential in order to stay tuned and work effectively.” His favorite thing about working at Silicon Labs is how we share knowledge within the company. He continued, “No matter what problem I face, I can always find a person who is willing to help. This generates a friendly environment where confidence and know-how can easily be built.”
When Csongor is not working on ICs or EVBs, he plays soccer for a local amateur club. His position is midfielder which he compares to his Silicon Labs role. “[As midfielder,] I am responsible for connecting the team members. In a way, this is very similar to my applications engineering role at Silicon Labs: connecting teams and people to ensure the company’s success.”
We’re glad you’re on our team, Csongor. Keep up the great work!