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!