What’s cooking?

Walking into a customer’s lab recently I detected the tell-tale odor of insulation cooking.  One of the engineers I was with said “It always smells like that.  You get used to it.”  It shouldn’t.  Not a good sign.  High speed switches, fast network interfaces, and dense processing nodes all dissipate a lot of power as heat.  FPGAs are notoriously difficult when it comes to estimating power dissipation.  When heat is not adequately removed from a system we know the system will fail at an accelerated rate.  It is very important to consider and have a plan to manage thermal issues up front in any new design. 

Heat can be transferred via three mechanisms: conduction, convection, and radiation.  Conduction occurs in solids and the heat is transferred via motion of the molecules.  Convection is the transfer of heat via a gas or fluid so by definition it is not possible in a solid.  Radiation is the transfer of heat via electromagnetic waves.  The sun warms us via radiation.  In a packaged chip we get conduction from the die to the surface of the package and then convection from the package surface to the surrounding air.  The amount of heat transfer from the case to the air via convection is dependent on airflow.  It is important to note that, for both conduction and convection, temperature is directly proportional to the power dissipation and inversely proportional to area the heat is flowing through. 

In the picture below I’ve depicted a BGA package– the balls are the little circles on the bottom, a chip (clear rectangle) inside a package (crosshatched area) with a heat sink stuck on the top.  A model of the thermal impedance is drawn to the right. 

 

Simply put, thermodynamics tells us that:

                        Rja = Rsa + Rcs+ Rjc = (Tj-Ta)/Q

 Where Tj is the junction temperature,  and Ta is the ambient temperature.  Both are in degrees Celsius.  Q is power dissipation in Watts. Rja is the thermal impedance from chip junction to ambient air.  Rsa is impedance from the surface of the chip to ambient air, and Rjc is impedance from the junction to the chip. 

Typically, for telecom type systems, the max Ta is 50 degrees C plus a 10 degree C rise inside the box.  A typical semiconductor Tj is 115 degrees C.  Substituting in these values allows us to calculate the max Rja for different levels of power dissipation.   You can see that as the thermal impedance Rja increases the allowable power dissipation drops quickly, assuming constant Tj and Ta.

I recommend measuring case temperatures right on the chip package and then using the chip manufacturer’s specified Θjc ( I use the notation Rjc here) to calculate the junction temperature.  A good DMM with a temp probe can give reasonably accurate case temperatures in a pinch.  There are also thermal cameras and handheld infrared heat detectors with laser sighting for those with a bigger budget. 

As an example, a typical  Rjc for a BGA package is 0.18 C/Watt.  Lets look at the case temperature and see what we can conclude about the junction temperature inside.  We know that:

Rjc = (Tj-Tcase)/Q

0.18 = (Tj –Tcase)/Q

Tj = Tcase + 0.18Q

You can see that the junction temperature will track the case temperature closely (within a degree) for power dissipation of 5W and under. Above 5W it gets difficult to get the heat out of this package so the die temp is gonna rise and the failure rate will increase.   Working through, and managing these issues up front in a design cycle will save you from a lot of headaches and a smelly lab. 

The Road to 5G is Paved with Good Intentions

One morning couple of weeks ago I was sitting in my office watching the snow drift down and wondering when spring was going to arrive in New England.  Mr Coffee, as usual, had provided a fresh pot of hazelnut coffee and I had a bag of cinnamon donuts from a shop that still makes them by hand.  The thing about donuts is they put a solid foundation under your whole morning.  Breakfast of champions.  The phone rang, disturbing my deep thoughts.  The caller wanted to know if I would be willing to participate in a private discussion of 5G applications with a group at an upcoming conference.

One of the problems with talking in general about “5G applications” is that the phrase itself means different things to different people– and they all can be quite passionate and vocal about their favorite application.

From the telco perspective there are two markets for 5G services:  fixed wireless broadband and mobile 5G services.  Pretty simple.  The telcos have been actively engaged in acquiring spectrum and launching trials for the past year or so.  It’s pretty obvious where they are going– at least in the near term.  But many advocates, developers, and entrepreneurs see things differently.  They see at least 4 application areas:

  1. Fixed wireless broadband
  2. 5G cellular service as a faster extension of 4G service
  3. Internet of Things (IoT) network enabler with low energy, low latency, mobility, ubiquitous connectivity, security, and billions of nodes.
  4. Wireless network unification– replace WiFi, and a myriad of other short range wireless networks with one standard network.

I’m not one who believes spectrum is scarce, but it is highly regulated.  Spectrum allocation suffers from the same rent-seeking problems seen when government and corporations collide (or collude).   Applications 3 and 4 may require expansion into parts of the RF band (above 30 Ghz) that present big challenges.  The wavelength for these frequencies is in the range of 1 mm to 10 mm so it is called the millimeter wave band. The main problem is signals encounter much more attenuation at these wavelengths.  Thus they can’t travel as far as today’s cell signals do and they don’t penetrate walls well.   Since we can’t change the main culprits in our environment, walls, water vapor, and oxygen, we have to space the radio transmitters and receivers closer together and/or use beamforming technology to focus the signal only where it is needed.  Beamforming is spatial filtering– focus the signal energy where you want it like a flashlight does.  You focus your signal on the target rather than spread it all around.  Beamforming works great for fixed entities– like an antenna array in a factory talking to a machine bolted to the floor. Beamforming is much harder for anything moving rapidly– like a car.

The telcos are looking for ways to extend their cellular franchise and perhaps reduce cost in last mile connectivity.  Given the network architectures proposed though it remains to be seen if there is a compelling cost reduction in widespread fixed wireless broadband.  They may just stay with fiber/coax to the home. They may decide that fixed wireless broadband, given its much higher speed, is a good replacement for DSL though.

I see 5G cellular and WiFi as more complementary than one replacing the other.  WiFi Alliance says there are more than 30 billion WiFi capable devices in the world today. WiFi hot spots are ubiquitous.   Each technology continues to evolve to higher bandwidths.  The big chip and equipment providers like Cisco, Qualcomm, and Broadcomm are betting on both.   I don’t see application 4 as likely to happen.  Hmmm, but what about application 3?

The IOT and Big Data

We have had a remote monitoring application for some time now called BBD Control.  Typically we monitor temperature and various sensor voltages.  Time-stamping and logging measurements to a file are sufficient for many applications but the types and amount of data that can be collected today is remarkable.  To me, this is the true promise of the Internet of Things (IOT).  It is not about 5G connectivity so much as it is about getting accurate data in people’s hands.  I’ve seen sophisticated post-processing and analysis lead to great insight based on a simple log file of accurate data.  The promise of Big Data all starts with the data.   

As we got into more demanding applications we developed a web based interface that controls measurements and displays results in tabular format so you can check on things remotely using a web browser. Along the way we added an SMTP email capability to inform users of measurement results and alarms.  This turned out to be quite handy.  It is nice to be able to show someone an event happening in their system miles away while having a nice lunch at the Farmer’s Daughter ( a local favorite). 

Recently we got involved in a project to add AC power measurements to BBD Control. We measure and analyze power draw.  This entailed adding a small microcontroller based circuit board and fair amount of software to control and display the measurements.  It measures AC voltage, current, and frequency.  Then it calculates real, apparent, and reactive power. 

Here is a screenshot I grabbed of the power monitor in action. It is quite useful for applications like measuring power draw for a custom block chain processing engine running different software algorithms. We scroll the 10 most recent measurements in a table on the power monitoring page.  Measurements are initiated by clicking on the measure power button or they can be made automatically at fixed intervals.

Rapid Development with HW Building Blocks: Reference Designs

Second in a series…..

In the first post in this series we looked at using System on Chip technology to save time in developing an embedded system.  In this posting we look at the use of hardware reference designs.

Another resource that can save development  time is a reference design that uses components you want to use in your system.  These reference designs are typically provided by a semiconductor vendor but were designed by a third party.   A good reference design will at least include a working board, schematics, and physical design files that allow you to build your own hardware based on a working design.  This can be a real time saver.  Occasionally the source schematics are included and if you use the same schematic capture tool you can save a lot of time that would have been spent creating symbols and drawing schematics.  Most often though the schematics are in PDF format.

Sometimes you can get low level firmware, software drivers, codecs, or even higher level software included in a reference design.  A good reference design board will allow software developers to get going with a lot of their low level software and firmware before actual hardware development.  A working reference design board can also allow experimentation and verification of things like a critical task’s real time performance capability, boot up and reset issues, and power and thermal issues. There are tests you can run in seconds on a lab bench that are not practical in a hardware simulator.

There are important issues to consider when using a reference design.  A thorough design review of the reference design is necessary to avoid problems later on. The  assumptions for acceptable design practice made by the developer of the reference design  may not be the same as yours.  Find out this stuff up front, not via a call from an angry customer.  Also, carefully check any licensing issues or terms and conditions for copying a reference design.  Hardware licenses can be different than software licenses because they are based on  patent law not copyright law.  It’s important to know the difference.   A patent based license can control the use and manufacturing of your device based on their design documentation.   A copyright based license just controls the distribution of the design documents.  Having a lawyer review the license up front is always a good idea.

Free Tools for Embedded Engineers

One of the great things about working on embedded systems these days is the availability of high quality free tools.  Many of these tools are open source products maintained by a team of dedicated developers.  Sometimes they are produced by semiconductor companies to aid designers using their products and require registration to download.    All of these tools make life much easier for embedded developers and are easy to find via your favorite search engine.  Some of our current favorites are listed below:

  • Gnu Plot — an excellent plotting program for graphical analysis
  • Gnu Octave — a freely available alternative to MathCad
  • LTSpice — Spice simulator from Linear Tech — excellent tool, easy to use
  • GCC — open source compiler (no list is complete without GCC!)
  • Gedit — Easy to use  text editor with many handy features for writing software
  • Inkscape — High quality vector graphics drawing program
  • Wireshark — easy to use packet sniffer for your laptop
  • Xilinx Webpack — some device limitations but an excellent tool

Tradecraft: Source Synchronous Bus Timing Problem

Interfacing to a source synchronous bus with an FPGA can be a bit tricky.  Today’s FPGA tools provide lots of resources to help achieve timing closure inside the chip.  Sometimes though, the FPGA needs a little help external to the chip to meet timing.

I recently ran into a case where an FPGA connected to an Ethernet PHY over a GMII bus.  The GMII bus uses simplex point to point connections for transmit and receive.  The source end of the connection drives the clock.  Both the clock and data for the GMII “Transmit” connection were sourced from the FPGA.  Close inspection of the FPGA timing report revealed that the data could come out 118 picoseconds before the clock came out. It is important that both the setup and hold time requirements of the PHY be met.

It was necessary to ensure the clock arrived at the PHY before the data lines changed (zero hold time) and that the PHY’s setup time requirements were met.   The easiest way to do this was to delay the data lines a small fixed amount by running them as longer nets than the clock line.   This ensures most of the clock period for setup time at the PHY and still maintains a 0 ns hold time.    The exact board propagation delay number is based on the dielectric constant of the circuit board and can be calculated by a circuit board vendor given the details of a board.   My general rule of thumb for delay in a stripline trace is about 165 ps/inch.  Sometimes a little propagation delay is a good thing!