Building bridges: Specifying and refining inteRFace designs
Virtually every product design must bridge the digital abstraction and the real analog world. A few considerations early in the design phase can focus an interface design.
By Joshua Israelsohn, Contributing Technical Editor -- EDN, 11/8/2007
Technological innovation during the second half of the 20th century came at an unprecedented pace, and, unlike earlier times, many advances during this interval moved rapidly into the broad consumer market. Because our society, until that time, tended to wring the full value and lifetime from a consumer good, marketers needed to generate sufficient excitement for new products to cause customers to switch in advance of necessity: the origin of the disposable economy.
Starting in the 1950s, advertising copy used phrases such as “jet age,” “atomic age,” and “Space Age” to connect products to a societal image of emerging and rapidly changing modernity. Ironically, perhaps, none of these phrases had much staying power save one: the “digital age,” which, beginning in the 1970s, correctly suggested that associated goods weren't simply modern but were manifestly different from products of earlier times.
Indeed, the digital abstraction has revolutionized our industry, almost every sector of our economy, and all but a few aspects of our lives. Though the effects have been quite real, this abstraction is, as all are, strictly conceptual. As a
result, virtually every product design must bridge the digital abstraction and the real analog world.
This requirement is remarkably fractal-like: Layout considerations within an IC, the inteRFace between an IC and its PCB, the PCB's layout, the product interface to points beyond the box, systems of boxes, and networks of systems all must contend with essentially similar interface concerns. This observation holds despite these items' enormously different scales, which can span more than 10 orders of magnitude. It is also the case that, though interface challenges grow with bandwidth, the issue arises throughout the spectrum.
A few considerations early in the design phase can focus an interface design. A consequence of the fractal-like traits of interfaces is that you can begin specifying interface requirements at the product-definition phase and refine them at the block-diagram, schematic, and simulation phases.
I distinguish this process of design refinement from iterative design—design refinement being a purposeful process of design in phases, and iterative design being a sequence of design repairs. The first pass at the product-definition phase should allow you to establish a good rough estimate for an interface's cost, complexity, and design time. The first phase's output can serve as your check as an implementation takes shape at the block-diagram phase. Disparities in cost or complexity estimates from the first and second phases serve as warnings against one of three conditions:
The interface design is heading off into the toolies.
The first phase failed to account properly for all product-definition requirements.
Changes to the product definition have made obsolete the cost and complexity estimates, and these estimates require updating as part of your project-management activities.
Make similar checks at subsequent design phases.
As a phase-one starting point, bear in mind the signal-source, -line, and -client attributes for each interface. Despite your signal's “digital” significance, remember that interface behaviors are analog and multiparametric. Take into account each line's bandwidth requirement, source impedance, signal magnitude, and run length; the characteristics of the connecting media; and the presence of noise sources or interferers, all in the context of the receiver-side circuit's signal-fidelity requirements. In the simulation phase, compare the transmitter- and receiver-side waveforms under the worst-case combination of these measures. Consider pre- and post-signal-conditioning techniques to correct deficiencies. If you delay these observations until prototype evaluation, you may slip from design refinement into a more costly course of iterative design.