Official Blog of Silicon Labs

    Publish
     
      • 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.

      • Silicon Labs Supports Women in Tech

        LeighPankonien | 10/303/2017 | 05:57 PM

        Silicon Labs CMO Michele Grieshaber takes a moment to review one of Silicon Labs' four core values.

        We hire, foster and empower great talent. 

        • We look for technical skill, creativity, and the potential to do great things. 
        • We value big-picture thinkers and cross-functional doers. 
        • We create an environment of trust and encourage open, two-way communication.

        At Silicon Labs we believe this great talent can come from anywhere and anyone. Therefore we support a diverse workforce, from gender to age to ethnicity to sexual orientation, and so on. We also support and believe in the importance of STEM initiatives around the globe. Venn diagram these and you’ll get Women in Tech. 

        Our Chief People Office, Lori Knowlton, elaborated on our support of women in tech in a recent article: “Women bring new ideas and perspectives to the table. And in doing so, they open the door to well-rounded thought processes that create better, more flexible products and higher performing teams. Successful teams employ a combination of left-brain and right-brain thinking. Companies who deeply understand and invest in the value of diverse, inclusive thinking are outperforming and outthinking their competition. By three times.” 

        Within the last couple of years a grassroots movement was started by a few women at Silicon Labs with the mission focused on support, inclusion and driving change. It started as a get-together by a small group within a specific department and has since expanded to include anyone who wants to participate within the organization. The Women @ SiLabs group is currently lead by Holly Ammerman, a Senior Product Marketing Engineer, and co-chaired by Renee Curfman, our Director of IT Infrastructure Services. One example of this group driving change is its work with the senior leadership team, and one-on-one with current and future women to make sure they’re growing and have all the opportunities awarded to them so they can help Silicon Labs get to where it needs to be.

        Renee Curfman shares her perspective: “We have this opportunity to really bring amazing innovation and change to this industry. I think we can get there faster and we can get there better if we do even more to open up that conversation and include more women. There’s always more work to be done to demonstrate your commitment to diversity and having different values and frames of mind at the table will propel us forward faster.”

        We believe it’s very important to amplify these voices and to engage in a conversation about gender and diversity. Hear the advice some of our employees give to women trying to break into the tech industry:

        While this video represents just a few of the gems these ladies shared, we’ll continue to share more of their powerful thoughts on our social media channels. We encourage you to follow along and join in the conversation. 

        Let’s continue the conversation:

      • Mission to Build a More Connected Community

        deirdrewlahs | 10/301/2017 | 10:14 PM

        Hi, community members! 

        As I'm sure you can tell, we launched an improved Silicon Labs community experience we are calling The Red Planet. 

        But this is more than just a facelift. The community will continue to be a great space for you to ask technical questions, share your ideas, and learn more about our latest solutions; however, we do have some key changes. We now have higher quality search, a product-centric architecture, and improved integration between our technical resource library and the community.

        Here are some things to get you started: 

        1) Update your profile

        2) Review the community guidelines

        3) Read about our new ranking and reputation structure

        4) Please share your feedback on the new experience. 

        Our mission is to help you build something great, and we look forward to hearing from you! 

      • Employee Spotlight – Helge Langen

        Lance Looper | 10/300/2017 | 09:35 AM

        Helge Langen joined Silicon Labs as a summer intern during the summer of 2016. In his current role as Hardware Engineer for the IoT MCU & Wireless team in Oslo, Langen’s responsibilities include hardware design, design testing and firmware development. He said his role requires him to “combine technical knowledge with creative skills to achieve the desired level of esthetically pleasing products.” His typical day at the office entails working on a variety of projects that can range from using a computer, a microscope and tweezers or even a hammer!

         

        spotlight-banner1.jpg

         

        His supervisor, Jørn Norheim said Langen is great at his job and requires little or no detailed information. He continued, “Regularly we get into the situation where I say, ‘Oh, [Langen] already did that thing I was thinking we should do to get the project completed. Well, that’s nice!’” Norheim continued, “He’s the sort of person that does not spend too much time talking, but rather spends his time on doing. Really, really well.”

         

        Langen’s favorite thing about working at Silicon Labs is he gets to do things he enjoys every day with a team of nice, talented people, while having fun. In addition to his day job, Langen is an avid runner. In fact, Norheim calls him “one of Norway’s best runners.” Langen said his favorite Silicon Labs value is ‘we do the right thing’ because it reminds him of when he’s running. “The competition is sufficiently fierce to force me to do the right things at practice every day to keep up – since there will always be someone else doing the right things most of the time as well,” he said. “Having success in the semiconductor business requires no less attention to continuous improvements.”

         

        Helge Langan, we’re glad you’re on the Silicon Labs team. Keep up the great work!

         

        Helge Langen_blog.jpg

      • KRACK Vulnerabilities and Protecting Deployed Products

        Lance Looper | 10/298/2017 | 12:35 PM

        Recently a vulnerability called KRACK in Wi-Fi security, which exploited the Key Reinstallation process part of WPA2, was discovered and published by researchers. This impacts all manner of Wi-Fi-based devices, including phones and laptops, but more importantly it’s affecting connected cameras, bulbs, medical devices, and HVAC systems as well. This class of devices, referred to as IoT devices, are especially vulnerable because they don’t come with an easy way to locate, identify, and update them in the field. Since these devices do not have a user interaction model or attendant management infrastructure such as the ones that are taken for granted with smartphones, they are at risk for an extended period of time.

         

        Vendors are, rightly, working diligently to make software updates available that will patch the issue. Even after the patch is made available, the issue still remains because distributing these updates to the product fleet is a significant gap. Current retrofitting processes, such as emailing customers or dispatching field service teams to update the products, are simply too slow, expensive, or do not provide enough coverage. According to HD Moore, a network security researcher at Atredis Partners, some of these devices may stay vulnerable for decades[1].

         

        The solution lies in designing in an efficient device management service for product fleets, be it consumer or commercial connected products, from day one as insurance against future vulnerabilities. The service needs to have three key aspects:

         

        1. End-to-End security that addresses data at rest security on the product itself, which includes data encryption. This, coupled with data in motion security, ensures data sent to and received from the device from any cloud service is fully protected.
        2. A management platform that can identify, authorize, provision, activate, and deactivate devices from production to in-field deployment and eventual end-of-life of product.
        3. An efficient software update distribution mechanism that can update products in the field reliably without bricking the device fleet at scale.

         

        Silicon Labs’ offers a solution to this problem in the form a cloud-based service called Zentri Device Management Service. This is a hardware agnostic service that is already helping customers identify the security posture of their fleet and apply software updates gradually or all at once. Additionally, the service can monitor the security fleet and be used to selectively disable or de-activate compromised devices.

         

        Learn more at zentri.com and sign up for additional information here.

         

         

        [1] https://www.wired.com/story/krack-wi-fi-iot-security-broken/

         

         

      • Timing 101: The Case of the Jitterier Divided-Down Clock

        kgsmith | 10/296/2017 | 12:47 PM

        Hello and welcome to the “Clocktoberfest” edition of the Timing 101 blog from Silicon Labs.

         

        Nice weather is starting to arrive here in central Texas. By late September and October we get hints of cooler and less humid days to come. Those of us of German descent, and plenty who are not, may celebrate Oktoberfest or some local variant such as Wurstfest in nearby New Braunfels. So “Happy Clocktoberfest!” from the Timing group.

         

        This month I am going to discuss a very common question that arises when measuring the phase noise and phase jitter of relatively low clock frequencies. All things being equal, we generally expect divided-down lower frequency clocks to yield lower phase noise than higher frequency clocks. Quantitatively, you may recall this as the 20log(N) rule.

         

        However, the 20log(N) rule only applies to phase noise and not integrated phase noise or phase jitter. Phase jitter should generally measure about the same. Further, as we get low enough in frequency we do not find this relation to hold true in actual measurements. So the question this month is - why is that?

         

        The 20log(N) Rule

        First, a quick review of the 20log(N) rule for those who may not be familiar with it:

        If the carrier frequency of a clock is divided down by a factor of N then we expect the phase noise to decrease by 20log(N). For example, every division by a factor 2 should result in a decrease of phase noise by 20log(2) or about 6 dB.  The primary assumption here is a noiseless conventional digital divider.

         

        Why is this? The output of a practical digital divider is rising and falling edges with the signal at a logic high or low level otherwise. Jitter is presented at the rising and falling edges only. The proportion of jitteriness to each clock cycle is reduced. Our intuition may suggest that if we reduce the number of jittery edges then we reduce the jitter transmitted by the divided down clock. That turns out to be correct.

         

        Formally, this can be written as follows:

        20log(N).png

         

         

         

        What About Phase Jitter?

        We integrate SSB phase noise L(f) [dBc/Hz] to obtain rms phase jitter in seconds as follows for “brick wall” integration from f1 to f2 offset frequencies in Hz and where f0 is the carrier or clock frequency.

        phase jitter.png

         

        In practice the quantities involved are small enough for good clocks that the RMS phase jitter, for a 12 kHz to 20 MHz jitter bandwidth, is on the order of 10s to 100s of femtoseconds.

         

        Note that the rms phase jitter in seconds is inversely proportional to f0. When frequency is divided down, the phase noise, L(f), goes down by a factor of 20log(N). However, since the frequency goes down by N also, the phase jitter expressed in units of time is constant. Therefore, phase noise curves, related by 20log(N), with the same phase noise shape over the jitter bandwidth, are expected to yield the same phase jitter in seconds.

         

        An Example

        Let’s look at a specific example. As an experiment, I took an Si5345 jitter attenuator, input a 25 MHz clock, and configured it so that I only changed an (internal) output divider by factors of 2 to obtain frequencies running from 800 MHz down to 50 MHz. I then measured the phase noise using an Agilent (now Keysight) E5052B and compared the phase noise and phase jitter for each case. Five runs were averaged and correlated for each frequency. I omitted any spurs for clarity and to simplify the experiment.

         

        Through the magic of MS Paint and use of the “Transparent Selection” feature I am able to overlay all of the E5052B screen caps as follows. (If the runs are identical each time only unique text is obscured.) In the figure below, the traces generally run top to bottom in descending carrier frequency, i.e. 800 MHz, then 400 MHz, etc. on down to 50 MHz. The shapes of the curves are the same except where the curves are compressed at the highest offset frequencies.

        Example.png

         

        I then tabulated the measured phase jitter results over the 12 kHz to 20 MHz jitter bandwidth as follows:

         

        Timing Table.png

         

        There are two immediate observations we can make from the overlaid plots and the table.

         

        1. The separation between the curves is close to what we would expect applying the 20log(N) rule until the traces begin to appear compressed toward the 100s of kHz to MHz offset

         

        1. The RMS phase jitter in fs is approximately the same for 800 MHz down to 200 MHz. However, for the 100 MHz and 50 MHz cases the expected phase jitter is way

         

        Despite the 20log(N) rule, the phase jitter is getting worse as I decrease the output clock frequency, especially below 200 MHz. These lower frequency clocks measure far jitterier than expected. Thus arises the case of the jitterier divided-down clock.  So what’s going on?

         

        Curve compression due to the apparent phase noise floor appears responsible for the differences in the calculated RMS phase jitter. Let’s verify that by comparing the data from 10 kHz to 20 MHz offset for the 800 MHz and 100 MHz cases. All of the spot phase noise data came from the original markers plotted except for the 20 MHz points which were estimated from the screen cap plots. (Note that for a factor of 8 or 23 we would expect a delta of 3 x 6 dB or 18 dB in phase noise.)

        Table2.png

         

        Taking just these values and entering them in to the Silicon Labs online Phase Noise to Jitter Calculator we obtain the following.

         

        Table 3.png

         

        Not too shabby for the online calculator considering it only had 5 data points to work with!

         

        Now let’s modify the 100 MHz dataset to remove the higher offset frequency compression as follows. The 18 dB Δ is as would be otherwise expected applying the 20log(N) rule.

         

        Table4.png

         

        Entering the modified values in to the online calculator we add its calculation to the table as highlighted:

         

        Table5.png

         

        This exercise confirms that the curve compression accounts for the significant difference in phase jitter

        measured between the 800 MHz and 100 MHz cases.

         

        The Noise Floor

        All of the traces flatten or get close to flattening by 20 MHz offset. So, what is the apparent or effective noise floor? Note that in general this will be some RSS (Root Sum Square) combination of the instrument phase noise floor and the DUT’s far offset phase noise. For example, if both the DUT and the instrument had an effective phase noise of –153 dBc/Hz at 20 MHz offset then the RSS result would be 3 dB higher or –150 dBc/Hz.

         

        If the instrument noise floor was well below the DUT's we would expect the spot phase noise at 20 MHz offset to decrease by 6 dB, for every division by a factor of 2, from that measured for the 800 MHz clock. But that is not what happened. See the table and accompanying figure below:

         

        Table 6.png

         

        Phase Noise.png

         

        The phase noise floor is not varying monotonically which suggest multiple factors may be involved. Reviewing the E5052B specs indicates that the SSB phase noise sensitivity should decrease slightly as the carrier frequency is lowered. Also, far offset phase noise from the DUT (Device Under Test) is typically dominated by the output driver’s phase noise and that’s unlikely to vary in this way. We are most likely running in to a combination of the instrument's "actual" phase noise floor as a function of input frequency plus aliasing on the part of the DUT. The Si5345's frequency divider edges can be regarded as sampling the phase noise of the internal clock presented to the divider. This factor is independent of the instrument. It is understood that aliasing can occur but quantifying the specific contribution due to aliasing can be problematic.

         

         

         

        This paper suggests that provided the noise BW of the input signal is > 4 x divider output frequency v0 then divided PM (Phase Modulation) noise will degrade via aliasing by 10log[(BW/2v0) +1]. The aliasing described primarily impacts the far offsets where we are interested.

         

        The authors write:

        "Aliasing of the broadband noise generally has a much smaller effect on the close-to-carrier noise

        because it is typically many orders of magnitude higher than the wideband noise."

         

        In these particular measurements, estimated noise floor degradation for the lowest carrier frequencies are plausible assuming a given BW and instrument noise floor. However, no one solution appears to accommodate all the data. It might require operating the device at the highest output frequency and then employing external dividers and filters to properly sort this out. Perhaps in some future post.

         

        Additional Reading

        While this month's post has concentrated on phase noise, it should be noted that divided spurs can be aliased or folded in the same way as the authors cited above discuss. One of my colleagues has demonstrated this also and I recommend his article for further reading.

         

        Conclusion

        We have reviewed the impact that a phase noise instrument’s apparent or effective phase noise floor can have on both the phase noise curve and phase jitter measurement of sufficiently low frequency clocks. After you have worked with your DUTs and phase noise equipment for some time you will recognize what a typical phase noise curve will look like, the approximate phase noise floor of the equipment, and what are reasonable expectations for phase jitter. Certainly, for the cases above, we would take have to take phase jitter measurements below 200 MHz with a grain of salt. If in doubt, try a similar configuration at a higher frequency for comparison. You will only miss the secondary phase noise degradation due to any instrument noise floor variation and/or aliasing due to higher division factors.

         

        As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to kevin.smith@silabs.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.

         

         

        Endnotes

        1. The derivation here is adapted from a slim but information packed book by Dr. William “Bill” Egan

        called Frequency Synthesis by Phase Lock published in 1981. See section 4.5, “Effect of Modulation

        of a Divided Signal”, pages 75-76. (There is a later and much expanded edition of this book.) Dr. Egan

        has passed on but he was a great engineer, author, and teacher in Silicon Valley. He wrote several

        excellent, clear, and precise books on frequency synthesis, PLLs, and RF systems design.

         

        2. A. SenGupta and F.L. Walls, “Effect of Aliasing on Spurs and PM Noise in Frequency Dividers”, 2000

        IEEE/EIA International Frequency Control Symposium and Exhibition, pages 541 – 548.

        Retrieved from http://tf.boulder.nist.gov/general/pdf/1380.pdf.

         

        3. H. Mitchell, "Perfect Timing: performing clock division with jitter and phase noise measurements", EE

        Times, 8/25/2011. Howell's paper covers this topic from a different perspective with some additional

        detail using data from the previous generation Si5324. He also demonstrates spur aliasing by mixing the

        outputs of separate RF signal generators. Retrieved from

        https://www.eetimes.com/document.asp?doc_id=1279033.