Embedded Computing Design - April 2006

Transcription

RSC# @ www.embedded-computing.com/rsc
BUILT
TO LAST
Fanless EBX 733MHz P3
with COM, dual ENET,
USB and Video
•VIA 733MHz or 1GHz C3 CPU
•PC-compatible, supports Windows® XP, CE, Linux and x86 RTOS
•Up to 512MB PC133 SDRAM
•Up 1GB bootable DOC ®, 512KB SRAM, or 1MB EPROM
•Type I and II CompactFlash cards supported up to 2GB
•CRT, flat panel, and LVDS
•Two 10/100 Ethernet controllers
•Four USB ports
•Four serial COM ports
•LPT, Kybd, and mouse
•48 bi-directional I/O lines
•Two EIDE and one floppy disk
controller
•AC97 Audio supported
•PC/104 & PC/104-Plus expansion
•+5 volt only operation
•EBX size: 5.75" x 8.0"
(146 mm x 203 mm)
•-40° to +85°C operation (733MHz)
•Quick Start Developers Kits for
Windows® XP, CE, and Linux
•Immediate availability
The EBC-C3 embeds 9 different functions to
provide a processor- and I/O-intensive solution.
It operates over a -40° to +85°C temperature range
without the need of a fan, making it ideal for
embedded applications such as robotics,
MIL/COTS, transportation, pipeline, and machine
control.
It runs Windows® CE, Windows® XP embedded,
Linux, and other operating systems as VxWorks
and QNX. And its x86-PC software compatibility
assures a wide range of tools to aid in your
application’s program development and checkout.
Call 817-274-7553 or
Visit www.winsystems.com
Ask about our 30-day
product evaluation!
WinSystems
715 Stadium Drive • Arlington, Texas 76011
Phone 817-274-7553 • FAX 817-548-1358
E-mail: [email protected]
TM
®
w w w. e m b e d d e d - c o m p u t i n g. c o m
7 Editor’s Foreword
Alliances, consortiums, and trade organizations
By Jerry Gipper
SPECIAL: How embedded computing is making
new consumer electronics possible
17 Embedded? Consumers are soaking in it
9 Embedded Europe
Embedded world highlights
By Hermann Strass
12 Eclipse Perspective and News
How Eclipse fits with embedded development
By Madison Turner and Robert Day
EVENTS
ESC Silicon Valley
Server Blade Summit
April 3-7 • McEnery Convention Center, San Jose, California
www.embedded.com/esc/sv
April 18-20 • Hyatt Regency, Garden Grove, California
www.serverbladesummit.com
Page/RSC# Advertiser
Product description
10 ACCES I/O Products 44 Advantech
16 Annapolis Micro Systems
11 Arcom Control Systems
42 Axiomtek
2 Diamond Systems
45 EDT
8 Embedded Planet
1402 Grid Connect
13 Hellosoft
7 Hunt Engineering
601 ICP America
47 Intel
48 Interactive Circuits & Sys.
22 Kontron
5 Micro/sys
15 Moxa Technologies 27 Precision Analog Systems
24 Radian Heatsink
602 SCIDYNE
29 Sundance 21 Technologic 32 Themis Computer
37 Toronto MicroElectronics
34 Tri-M Systems
35 Tri-M Systems
1401 VMETRO
3 WinSystems
Analog, Digital, Relay and Serial I/O
SOM Solutions
FPGA Systems
Apollo Fanless Computer
Embedded Solutions
Embedded Solutions
PCI Boards
Hardware and Software Solutions
Ethernet Software
HelloIP-PhoneT
USB Connected Programmable FPGA Systems
GoPC-Mobile
Architecture and XScale
ICS daqPC
ETXexpress-CD
EBX, EPIC, PC/104
UC-7420
Analog and Digital I/O Cards
CFD Simulations and Custom Designs
PC/104 Peripherals
SMT498 prPMC FPGA Module
Linux FPGA Computer
Themis Slice
Embedded Computer Solutions
ECM401
Micro-P3
MOPSlcd7
TMZ104
PCI Express
Fanless EBX 733MHz P3
By Don Dingee and Jerry Gipper
TECHNOLOGY: Data acquisition
23 A low-cost, on-site, reconfigurable client DAQ system
30
By Srirama Chandra, Lattice Semiconductor
Image fusion: Shared memory supports flexible, multiple
sensor imaging systems
By Ralph Barrera, Curtiss-Wright Controls Embedded Computing
APPLICATION: Home systems – entertainment,
security, control, monitoring
33 Bringing programmability to the CE market: Winning design
strategies
PRODUCT GUIDE
39
FPOAs surmount multimedia decoding hurdles
41
Product listings: Devices – ASIC, DSP, FPGA, SoC, microcontrollers
By Todd Scott, Altera
42
By Sean Riley, MathStar
PCI EXPRESS
Avoiding unexpected challenges in PCI Express core integration
By Tony Sousek and Nick Sgoupis, CAST
E-CASTS
New VITA standards: Strengths, weaknesses, target applications,
and what you need to know to be able to differentiate between them
April 25, 2 p.m. EST
www.opensystems-publishing.com/ecast
X-Midas Applications for Small Spaces and Harsh Environments
May 3, 11 a.m. EST
www.opensystems-publishing.com/mercury.html
E-LETTER
www.embedded-computing.com/eletter
Embedded software drives the digital home
By C.C. Hung, Mentor Graphics, and Richard Schmitt, Blue Peach
WEB RESOURCES
Published by:
© 2006 Embedded Computing Design
All registered brands and trademarks within Embedded Computing Design
are property of their respective owners.
/ April 2006
APRIL 2006
FEATURES
COLUMNS
Volume 4 • Number 3
Embedded Computing Design
OpenSystems
Subscribe to the magazine or E-letter:
www.opensystems-publishing.com/subscriptions
Industry news:
Read: www.embedded-computing.com/news
Submit: www.opensystems-publishing.com/news/submit
Submit new products:
www.opensystems-publishing.com/vendors/submissions/np
A
O
n
p e n
S
y s t e m s
P
u b l i c a t i o n
Embedded and Test & Analysis Group
n
n
n
n
n
n
n
n
Embedded Computing Design E-letter
Embedded Computing Design Resource Guide
Industrial Embedded Systems
Industrial Embedded Systems E-letter
Industrial Embedded Systems Resource Guide
PXI, Test & Technology
PXI, Test & Technology E-letter
Editorial Director Jerry Gipper
[email protected]
Contributing Editor Don Dingee
Technical Editor Chad Lumsden
[email protected]
Associate Editor Jennifer Hesse
[email protected]
European Representative Hermann Strass
[email protected]
Special Projects Editor Bob Stasonis
Senior Designer Joann Toth
Senior Web Developer Konrad Witte
Graphic Specialist David Diomede
irculation/Office Manager Phyllis Thompson
C
[email protected]
RSC# 01 @ www.embedded-computing.com/rsc
OpenSystems Publishing
Editorial/Production office:
16872 E. Avenue of the Fountains, Ste 203, Fountain Hills, AZ 85268
Tel: 480-967-5581
OpenSystemsn Fax: 480-837-6466
™
Publishing
Website:
www.opensystems-publishing.com
Publishers John Black, Michael Hopper, Wayne Kristoff
Vice President Editorial Rosemary Kristoff
Communications Group
Editorial Director
Assistant Managing Editor
Senior Editor (columns)
Technology Editor
Associate Editor
European Representative
Joe Pavlat
Anne Fisher
Terri Thorson
Curt Schwaderer
Jennifer Hesse
Hermann Strass
Military & Aerospace Group
Group Editorial Director
Managing Editor
Assistant Editor
Senior Editor (columns)
European Representative
European Bureau Chief
Chris Ciufo
Bonnie Crutcher
Sharon Schnakenburg
Terri Thorson
Hermann Strass
Stefan Baginski
ISSN: Print 1542-6408, Online 1542-6459
Embedded Computing Design is published bi-monthly by OpenSystems Publishing
LLC., 30233 Jefferson Ave., St. Clair Shores, MI 48082.
Subscriptions are free to persons interested in the design or promotion of embedded computing systems. For others inside the US and Canada, subscriptions are
$56/year. For 1st class delivery outside the US and Canada, subscriptions are
$80/year (advance payment in US funds required).
Canada: Publication agreement number 40048627
Return address: WDS, Station A, PO Box 54, Windsor, ON N9A 615
POSTMASTER: Send address changes to Embedded Computing Design
16872 E. Avenue of the Fountains, Ste 203, Fountain Hills, AZ 85268
/ April 2006
Alliances, consortiums, and
trade organizations
n preparing our report on the Consumer Electronics Show
(CES), it struck me how often we wound up at various alliance
booths during the show. Companies often rally around a
market or a technology to promote it to potential users and/
or to develop supporting degrees of standards using this
technology.
Many developer alliances in existence drive and standardize
technology. OpenSystems Publishing tracks more than 75 alliances, consortiums, and trade organizations of various types that
complement the embedded computing industry in some fashion.
One or two new organizations seem to be added to the list each
month. Some of these alliances or consortiums are ecosystems for
specific suppliers or a technology. The founding supplier usually
sets the standards while the alliance members promote their
products based on this standard. Others are market/technology
trade associations that collaborate on defining the technology
for next-generation development. Several are even accredited
by recognized standards bodies to develop official technology
specifications.
Many companies hedge their bets by participating in multiple
alliances, consortiums, and trade organizations even though they
compete or overlap in nature. This sometimes makes validating
a company’s true strategy or direction and understanding a company’s goals confusing.
Jerry Gipper
to give electronics designers a leg up on staying ahead of the
technology curve.
■ FPOAs surmount multimedia decoding hurdles, composed by
Sean Riley of MathStar. Field Programmable Object Arrays
(FPOAs) are high-performance programmable logic devices
programmed at the object level instead of the gate level. Sean
introduces us to this new class of programmable devices and
how they can be used in decoding MPEG2 video.
■ Avoiding unexpected challenges in PCI Express core integration, written by Tony Sousek and Nick Sgoupis of CAST,
Inc. The authors discuss various pitfalls and options to avoid
them in developing your own PCI Express end-point controller using off-the-shelf intellectual property.
Your suggestions and comments are welcome. Please contact me
at [email protected].
Jerry Gipper, Editorial Director
We invite embedded computing alliances, consortiums, and trade
organizations to contribute their stories to us so that we can convey
relevant information to the general embedded computing industry.
I would also like to hear from embedded computing technology
users on your opinion of whether these organizations help you
make technology decisions.
This issue, in the meantime, covers:
■ In Embedded? Consumers are soaking in it, Don Dingee and
I discuss our observations of the 2006 CES. We embarked
on a mission to find applications of embedded computing
technology at the largest electronics show in North America.
Read this to learn what we discovered.
■ A low-cost, on-site, reconfigurable client DAQ system, written by Srirama Chandra of Lattice Semiconductor. Srirama
discusses how to design a cost-effective and reconfigurable
data acquisition system using FPGA technology.
■ Image fusion: Shared memory supports flexible, multiple
sensor imaging systems, authored by Ralph Barrera of
Curtiss-Wright Controls Embedded Computing. Highdefinition images are used in a large number of applications.
Higher definition is often achieved by throwing more pixels
and more bandwidth at the images. Ralph shows us one
way to make improving the definition by combining images
from multiple sensors possible.
■ Bringing programmability to the CE market: Winning design
strategies, penned by Todd Scott of Altera Corporation. Given that consumer electronics have notoriously short market
windows, Todd considers ways to use programmable devices
April 2006 / 7
Embedded world
highlights
Events
The embedded world 2006 exhibition and conference in Nuernberg,
Germany, is the world’s largest meeting place for embedded
technology experts. In February, three exhibit halls were filled
with more than 13,000 visitors from 27 different countries and
nearly 500 exhibitors showing hardware, software, and tools for
embedded computing. Conference attendees could choose from
24 sessions with multiple presentations, tutorials, and workshops.
Attendance was up 22 percent from last year, with 35 percent of
the exhibitors hailing from overseas.
A jury of experts selected this year’s embedded world award winners: NEC Electronics Europe in the hardware category, QNX in
the software category, and pls Programmierbare Logik & Systeme
(PLS) in the tools category. NEC showed the world’s smallest
microcontroller in a very small package of 1.9 mm x 2.2 mm
(less than one-tenth of an inch on both sides). This is a complete,
packaged microcontroller with flash memory in a performance
range from 3 to 20 MIPS. QNX received an award for their
true multiprocessing Real-Time Operating System (RTOS)
for multicore chips, available in asymmetric or symmetric and
bound multiprocessing variants. PLS, Germany, developed an
extremely efficient universal emulation configurator to analyze
data in on-chip emulators at a higher logic level than traditional
trace analyzers. The state machine-based system is independent
of source or emulation hardware.
By Hermann Strass
where you look. The stadium has 11,000 data points (sensors) to
monitor lights, heating, ventilation, sanitation, and all kinds of
measurement and control electronics. The translucent outside wall
of the stadium can be lit from the inside in various combinations
of red, white, and blue depending on which teams are playing.
Embedded systems also control the parking garage, touted as
Europe’s largest with capacity up to 9,800 cars. Siemens delivered
and installed all of the electrical and electronic systems.
STMicroelectronics, in France and Italy, has integrated a chemical
and biological lab with a processor on a silicon chip. The In-Check
System-on-Chip has all the necessary mechanical, thermal,
electrical, and fluidic connections or MicroElectro Mechanical
System (MEMS) technology with a microprocessor on a chip
Figure 1, courtesy of NuernbergMesse, shows happy award winners
and organizers at embedded world 2006, including, from left to
right: conference organizer Matthias Sturm, a professor from the
University of Leipzig; representatives from NEC, QNX, and PLS;
and exhibition organizer Bernd Diederichs of NuernbergMesse.
Automotive embedded electronics played a big role at embedded
world 2006. Chips and systems for FlexRay showed up in great
variety. A consortium of mostly European car manufacturers
developed FlexRay to be used in time-triggered reliable systems,
like drive-by-wire or brake-by-wire. Motor Control Units (MCUs),
which help further reduce gasoline consumption in car engines,
also made an appearance. TTTech, Austria, exhibited the first
time- and event-triggered system with sensor/actor management
certified to safety level SIL 3, which is used in off-highway
vehicles.
Several German companies, such as E.E.P.D., Lippert, and
Kontron, displayed dual-core embedded systems in various
embedded form factors. EUROS Embedded Systems GmbH
showed a version of their EUROS RTOS, which was specifically
developed for multicore microprocessor systems.
Applications
At the Allianz Arena in Munich, www.allianz-arena.de, currently
Europe’s most modern stadium for sports such as soccer and
European football, embedded control electronics turn up every-
Figure 1
7.62 mm x 2.54 mm (3" x 1"). It uses a personal computer for
displaying the results. With In-Check, analysis can take place at
the point of care, without having to wait one or two days for lab
results. This minilab handles DNA analysis and other biochemical processes.
The silicon chip can switch very fast between typical Polymerase
Chain Reaction (PCR) tasks at 94 °C, 72 °C, or 60 °C, eliminating
the need to transport the biochemical fluids between different
hot spots on the chip. The liquid stays in the microchannel inside
the silicon chip during temperature cycles. Heating elements and
temperature sensors are within micrometer distance on chip and
microprocessor controlled to ±0.3 °C accuracy. This temperature
precision is required for DNA analysis, which is further enhanced
by laser scanning of fluorescence in certain areas on the silicon
chip. Silicon in this case is superior to glass because of higher
light intensity. The fluidic part on this MEMS computer system
is based on experience gained in the mass production of inkjet
printheads.
April 2006 / This In-Check system is used for the detection of infectious
diseases, sepsis (blood poisoning), pneumonia, meningitis, water
pollution, food contamination, or biological warfare substances.
STMicroelectronics and Veredus Laboratories announced development of a fast, point-of-need diagnostic capability that will
enable health practitioners to quickly detect strains of avian flu and
other influenza viruses using In-Check. The diagnostic capability,
which uses reliable and inexpensive equipment, produces results
within approximately one hour of testing.
News
ELTEC and PHYWE, Germany, recently announced collaboration
with other companies to form the Open Source Automation
Development Lab (OSADL). OSADL members will be creating
a standardized and certified real-time Linux for industrial automation applications.
Atmel, Belgium, claims 35 percent better performance per instruction cycle in their new AVR32 microprocessor core compared
to an ARM 11 core. The Atmel core minimizes overhead from
load/store and branch operations and maximizes pipeline throughput of complex algorithms at a low clock rate and low power
consumption. One special feature is direct execution of block
cipher algorithms in cryptographic applications like Blowfish,
Triple-DES, and Rijndael (AES). Some parts of the AVR can
quadruple the throughput of DSP algorithms in Single Instruction
Multiple Data (SIMD) instructions, especially when running
under a Linux OS.
Upcoming E-cast:
New VITA standards: Strengths, weaknesses, target
applications, and what you need to know to be able to
differentiate between them
Moderator:
Chris Ciufo
Presented by: VMEtro, Curtiss Wright,
Tundra, Hybricon
Registration and archived E-casts available at:
www.opensystems-publishing.com/ecast
10 / April 2006
APRIL 25, 2006 – 2 p.m. EST
OpenSystems
Publishing™
PERSPECTIVE AND NEWS
How Eclipse fits with
embedded development
By Madison Turner and Robert Day
P
roviding tools for the embedded
software developer is a very
complex task. The wide range of
processor architectures, development host systems, Real-Time Operating
Systems (RTOSs), and application-specific
requirements has traditionally meant these
tools have been proprietary in nature.
Unfortunately, this means the embedded
software developer has had to relearn
and rebuy solutions all essentially doing
the same thing. No standard environment
or tool suite could meet all these diverse
requirements … until now.
Enter Eclipse. Born from the enterprise
space, this open environment is now providing a common platform that embedded developers can buy once, use many.
But, how exactly can this nonembedded
platform meet the needs of embedded
developers?
Eclipse is not a product; it is a framework.
It allows embedded vendors to plug in
proprietary tools into a common environment. Part of its appeal is that it actually
goes much further and defines the look
and feel of plug-ins, too.
For embedded developers, this means:
■ They have a common Integrated
Development Environment (IDE)
meeting many of their common
software development needs, such as
project management, version control,
and source code browsing
■ They also have access to tools meeting
specific embedded needs that plug into
the environment and offer a common
look and feel
Let’s examine a couple of examples of
embedded software tools used for different
purposes, but share this common IDE.
Debugging a Linux
application on a standard
COTS board
In this case, the embedded software team
is very software and application centric.
12 / April 2006
The team does not need deeply embedded
probes and hardware tools, as the application is running on debugged COTS hardware. Instead, much more attention is spent
on the software issues, not dissimilar to
the enterprise space. The standard Eclipse
platform offers a rich project navigation
and project management plug-in focused
on developing application software. The
CDT project from Eclipse adds some
specific C and C++ build tools that give
specific C/C++ editors and a sophisticated
build environment built around the GNU
compilers. For a Linux developer, this is a
good starting point to help manage source
files and Linux builds.
Each of the embedded Linux providers
also offers a debug plug-in to Eclipse
that allows the developer to debug their
embedded Linux applications, with full
awareness of the target hardware and what
the Linux operating system is doing as the
developer steps through the application.
This debugger is often connected to the
COTS board using standard Ethernet
connections, and hence doesn’t even
need hardware connection technology to
facilitate it. All of this is achieved without
leaving the Eclipse environment, and better still, is integrated with available software management products not specific
to embedded development.
Linux developers can take advantage
of open source for both the OS and the
tools, but also have an environment that
is embedded aware, of high quality, and
with a common Application Programming
Interface (API) to the tools used in hard
real-time systems if needed. This last
point becomes relevant when embedded
systems have a large application part that
can be well served by Linux and a hard
real-time part that needs to be serviced
by a hard RTOS. Eclipse can be used
for both.
Figure 1 displays an example of how
Eclipse can be used to debug Linux to
the thread level, showing LynuxWorks’
Luminosity IDE in action.
Debugging a hard-real
time system on proprietary
hardware
For more deeply embedded devices, the
Eclipse framework can utilize a debug
perspective that allows connection to the
target via the JTAG port available on most
embedded devices. Embedded developers
face the issue of the large number of target
boards that exists, each configured slightly or significantly different. Connection
wizards ease the process of establishing
a connection to an embedded target by
providing standard configurations for
popular targets and connection devices.
These wizards offer a centralized and
easy-to-use interface for specifying debug session parameters. For example,
the user can choose an output file to load
automatically and specify a symbol to run
to upon loading.
While a register view displays and modifies
register values, a variable view operates
similarly for the contents of variables
and data structures, with structures and
their members laid out hierarchically for a
logical and usable view of the target data.
A memory view displays and modifies an
address or address range. In these views,
values are displayed in the radix specified
by the user: binary, decimal, hexadecimal,
or octal. A memory map view graphically
displays the layout of the application in
target memory in terms of program sections, files, or functions.
The fastest way to say “hello” with VoIP
HelloIP-PhoneT™ stack integrates:
– media processing
– signalling
– SIP
– echo cancellation
– jitter buffer
– framework
Proven, portable code for IP handsets,
ATAs, mobile phones, carrier edge
equipment, and other VoIP clients
Optimized for single RISC processor with
industry-best performance and lowestcost for media processing algorithms
For more on HelloIP-PhoneT, see
www.hellosoft.com
2099 Gateway Place, Suite 200, San Jose, CA 95110
(408) 441-7110
[email protected]
LEADING MOBILE CONVERGENCE
With the addition of a
scripting language for
application-specific
debugging support,
the combination of an
Eclipse-based embedded
debugger and JTAG
probe can provide
Figure 1
With the addition of a scripting language
for application-specific debugging support,
the combination of an Eclipse-based embedded debugger and JTAG probe can
provide unprecedented levels of insight
into the target application. In this scenario,
scripts carry out debugging operations on
the target and format, manipulate, and
display that information on the host. In
this way, extremely sophisticated debugging techniques can be developed
specific to the application under test.
unprecedented levels
of insight into the
target application.
April 2006 / 13
Figure 2
For example, a block of target memory
values representing a video file can be
uploaded via JTAG and viewed in a media
player on the host to ensure the integrity
of the content. A tool such as the Mentor
Graphics Nucleus EDGE IDE shown in
Figure 2 supports these functions.
Another powerful feature that relies on
the Eclipse framework in concert with
a JTAG connection is kernel awareness
for a hard RTOS. Kernel structures, including tasks, communications mechanisms,
timers, and memory pools, are monitored
over the JTAG connection and made
easily navigable within the debug view.
Kernel-aware debugging makes it easy to
analyze task interaction, real-time logic,
and memory usage. It also makes taskspecific break-points available.
These examples show how the different hardware, software, and applicationspecific requirements typical in today’s
diverse embedded applications can be
united in a single development environment – powered by an open source platform
called Eclipse, the today and tomorrow of
embedded tool environments.
Madison Turner is a technology
analyst at Mentor Graphics Embedded
Systems Division, where he focuses on
next-generation development tools and
methodologies.
Robert Day is the vice president
of marketing for LynuxWorks. His
responsibilities include leading program
management teams and driving worldwide
marketing initiatives, including corporate
communications and brand strategy.
For more information, contact Madison or
Robert at:
Mentor Graphics
739 N. University Blvd.
Mobile, AL 36608
Tel: 251-208-3400
Website: www.mentor.com/embedded
LynuxWorks
14 / April 2006
855 Embedded Way
San Jose, CA 95138-1018
Tel: 408-979-3900
Website: www.lynuxworks.com
Embedded?
Consumers are
soaking in it
By Don Dingee and
Jerry Gipper
F
rom our perspective at Embedded
Computing Design, we see a consumer embedded computing market nearly six times the size of
the personal computer market. The
Consumer Electronics Association forecasts $135 billion in total factory sales
of consumer electronics in 2006 and PCs
represent less than $20 billion of that
number. The majority of devices included
in the remaining $115 billion forecast contain an embedded computing element.
Computers are being designed into everyday devices more and more, and devices under the broad label of consumer
electronics really are driving the revolution. And it’s a big playing field, so much
so that it has spawned the largest trade
show in North America, the Consumer
Electronics Show (CES) in Las Vegas.
When the words road trip were uttered,
the Embedded Computing Design editorial team jumped at the chance to pile into
a car and make the drive up to Las Vegas
for the couple of days in January to see
firsthand the spectacle that is CES. We
weren’t looking for the normal stuff,
although it was abundant; large screen
HDTVs, mobile phones, GPS devices,
personal media players, and the like were
easy to find. Instead, we were looking for
some of the novel ways embedded computing technology is being applied to
make our lives easier.
Multimedia devices morphing
One of the first displays seen before
even entering the hall was the Dresser
Wayne, www.wayne.com, Ovation iX
fuel dispenser, what most of us are
used to calling a gas pump. With
Microsoft Windows CE and
the Microsoft .NET framework
integrated, this fuel dispenser
does much, much more. It
integrates a full multimedia
station with a 10.4" color display
and speaker, enabling consumers
to engage with full-motion, sitespecific commercial content and
gain access to coupons, specials,
promotions, lottery tickets, traffic
reports – a whole range of information.
Dresser’s iX Technology Platform also
enables functions for retailers such as
advanced diagnostics, point-of-sale features independent of the in-store POS
system, and management of the multimedia functions and usage reports. We
contemplated that it would only be a
matter of time before the fuel dispenser
communicates directly via wireless to
your car to do a quick health check.
Another multimedia device we saw was the
Pepper Pad (Figure 1), www.pepper.com,
a 2.3 pound Linux-based handheld with
built-in Wi-Fi and Bluetooth, 20 GB hard
disk, 800 x 600 color LCD and touch
screen, keypad and navigation and scroll
controls, speakers and microphone jack,
USB, and an SD/MMC slot. Built as a
multimedia platform to run Java, flash,
and Mozilla-based applications as well
as C and C++ code, its Intel Xscale
PXA270 processor is coupled with an
Intel 2700G media processor to pack a lot
of power in a small package. It’s designed to be a quick, portable connection to
the Internet for e-mail, IM, videos, Web
browsing, and similar activities.
Figure 1
Serving up entertainment
It’s clear vendors are vying for where
and how media and data are stored and
exchanged in the home. Companies are
taking several different approaches with
devices dedicated to exchanging and
managing content for home entertainment
systems.
Multimedia home entertainment was a
major buzz area at CES. Vendors hawking
their solutions constantly surrounded us.
All seemed to have a common element of a
PC buried in the system somewhere, either
displayed obviously or hidden within a
new HDTV. Intel and Microsoft again
took the lead as they touted their solutions, Intel with their Viiv technology and
Microsoft with PlaysForSure. The brands
permeated the show as they competed to
gain mindshare.
The Multimedia over Cable Alliance
(MoCA), www.mocalliance.org, is targeting use of the existing cable infrastructure
in many homes as the main entertainment
backbone. According to the alliance, coax
April 2006 / 17
cable – made to carry high-quality, highspeed video signals – is in more than
70 percent of U.S. homes, and has large
amounts of unused bandwidth. The standard is based on high speed (270 Mbps),
high Quality of Service (QoS) signaling,
and the innate security of a shielded,
wired connection combined with state-ofthe-art packet-level encryption. Promoter
companies in the set-top box and cable
operator industry such as Comcast, Cox,
Dish Network, Linksys/Cisco, Motorola,
Panasonic, RadioShack, Toshiba, and
Verizon are behind this standard. Entropic
Communications, www.entropic-communications.com, also a promoter company,
and Octalica, www.octalica.com, currently
make chipsets for MoCA compliant devices. Entropic’s c.LINK chipset with an
RF interface and a baseband controller
and integrated MAC began shipping at the
end of 2004 and now leads the market, just
reaching the 500,000 mark as of March 1.
ED Digital launched their Digitrex,
www.digitrexusa.com, brand in the United
States with their first product for the
market, announcing what they call the
networked TV (Figure 2) featuring native support for Microsoft Windows
Media Connect technology. This allows
consumers to view pictures and movies,
and listen to music stored on their
Windows XP PC anywhere in their
home on the networked TV. The Digitrex
Network TVs are easy-to-use, full 1080i
LCD flat panels with wired and 802.11 b/g
wireless networking capabilities, and take
CDs, MP3s, recorded TV programs, and digital photos. EI offers the Life|ware approach,
unifying the user experience to control lighting, climate, security system, cameras, and
entertainment systems, all through the same easy-to-use interface and a single remote.
The SVP Alliance, www.svpalliance.org, focuses on creating standards for video processing chips to help protect content rights. Targeting set-top boxes, digital televisions,
and portable multimedia devices, the Secure Video Processor technology uses certificatebased licensing to protect content and allow enabled receivers to decrypt and decompress it.
By the way, one thing we couldn’t help but notice – if the television manufacturers have
their say, you will never buy another tube-based TV again. Everything is flat-panel
technology of one kind or another. There is also a big push for custom televisions with
cabinets and cases that can match any home or room décor. Mass customization is making
its impact on television.
Audio sounding great
Dolby Laboratories, www.dolby.com, exhibited a range of applications for their licensed
IP in a large booth, including automotive. In collaboration with Intel, Dolby is working to
create what they call the PC Entertainment Experience, a branded approach to delivering
high-quality, certified audio including the ability to author DVDs with Dolby Digital
surround sound.
Induction Dynamics has taken a high-density
iron-alloy magnetic material invented by the
U.S. Navy for sonar applications, Terfenol-D,
and designed it into a product called Solid
Drive (Figure 3), www.soliddrive.com, which
can transform a solid surface such as drywall,
glass, granite, or wood into a speaker. They
claim Solid Drive is omnidirectional at nearly all frequencies and maintains channel
separation. Now the walls will be able to talk
as well as listen.
Figure 3
Wolfson Microelectronics, www.wolfsonmicro.com, showed its new WM8569 singlechip stereo audio codec for DVD, personal video recorder, LCD TV, and automotive
applications. The WM8569 integrates D/A and A/D functions in a single 28-pin SSOP
device, operating on 24-bit sigma delta converters with sample rates of 192 kHz for the
D/A and 96 kHz for the A/D. Control is implemented with a simple 3-wire SPI, and the
device provides better than 100 dB signal-to-noise ratio.
All your homes are controlled by …
Similar to the home entertainment side, home automation and control strategies are also
varied, using several different network and user interface approaches. Control networks
tend to be simpler and lower cost.
Figure 2
advantage of Microsoft’s PlaysForSure
technology. Steve Jean, vice president of
marketing and product development for
ED Digital, said, “It’s never been easier
for consumers to enjoy all the music files,
digital pictures, and videos they’ve stored
over time, and share them with family
and friends, while relaxing in the comfort
and convenience of their living or family
entertainment room.”
Another company, Exceptional Innovation (EI),
www.exceptionalinnovation.com, showed
its Life|storage digital media storage server,
with 1.5 TB of RAID 5 storage for videos,
18 / April 2006
Home automation systems of one kind or another have been around for many years, but
there seems to be an inflection point initiating momentum in automation systems. It is
likely a combination of system costs, home costs, and fuel costs all coming together to
make it more practical for the typical home to become automated. The influence of home
multimedia centers is also evident as the media center can also be the brains for home
automation.
SmartLabs announced the first of its INSTEON chips, www.insteon.net, in its pavilion.
INSTEON, short for instantly on, a control network fast enough to be perceived as instant,
uses a dual mesh with both powerline wired and RF links inside the home, and can bridge
to other networks, including X10 and Wi-Fi. See the sidebar on INSTEON Home Control
Technology from SmartLabs for background and technical highlights. An alliance with
more than 300 member companies supports INSTEON including names like Somfy, First
Alert, Maya, Integration Associates, Elk, Visonic, Universal Electronics, and EI, and at
least 40 new products are in development for home automation roles including lighting,
security, comfort, and consumer electronics.
The Z-Wave Alliance, www.z-wavealliance.org, also had a pavilion with member
companies including Intermatic, Leviton, Logitech, and others showing various devices.
S I D E B A R
If the television
manufacturers have
their say, you will
never buy another
tube-based TV again.
Z-Wave is a low-cost, two-way wireless
mesh network product designed for
residential control systems based on a
chipset from Zensys, www.zen-sys.com.
The ZW0201 SoC (Figure 4) contains an
integrated RF transmitter, an 8051 microcontroller, flash and SRAM, and a range
of peripherals. It uses either 915 MHz
(United States) or 868 MHz (European
Union) with a lightweight, low-power
protocol, and is simple to maintain as
the network self-organizes and discovers
new nodes on command.
Figure 4
The HomePlug Powerline Alliance,
www.homeplug.org, sticks to powerlines
for its network. It is more than a simple
control network, however; there are actually four standards in use and development.
HomePlug 1.0 was the original standard.
Offering higher bandwidth services for
entertainment needs, HomePlug AV supports MAC bandwidths of over 100 Mbps.
HomePlug BPL delivers Internet access
through broadband powerline networking.
HomePlug Command and Control focuses
on very low-cost applications. Companies
such as Comcast, Earthlink, GE Security,
Intel, Linksys/Cisco, Motorola, RadioShack,
Samsung, Sharp, and Sony sponsor the
standards.
ZigBee, www.zigbee.org, is also gaining momentum, and we saw one of
its supporters, Hawking Technology,
www.hawkingtech.com, with their new
INSTEON home
control technology
puts developers
in control
By Dan Cregg
SmartLabs, the leader in home automation since 1992, has seen the consumer market
for home automation and control products increase for years. In that time, they also
identified a central reason why home automation has not seen the explosive growth
that PCs and wireless phones experienced: Simply no industry-standard technology
was strong enough, flexible enough, or smart enough to support it.
In 2001, SmartLabs began its quest to bridge the technological divide and bring
home automation for the masses within reach. SmartLabs engineers listened to their
customers, and more often than not, their complaints mirrored problems developers
have traditionally faced; namely, customers wanted something simple, reliable, and
affordable that wouldn’t be obsolete by the time they installed it. A tall order, but
SmartLabs fulfilled it with INSTEON, and the news is as good for developers as it is
for consumers.
One of the greatest hurdles in developing for home automation has been reliability.
Previous powerline solutions offered a limited command set and suffered from
unacknowledged signaling methods and common powerline issues such as phase
coupling. Existing wireless technologies demand complex routing strategies, complicated setup, and constant network supervision, and RF in the home often presents
coverage issues.
INSTEON has purposely been kept simple, both for designers and users, allowing control
nodes to be made at a very low cost. In an INSTEON network, shown in Figure 1, both
wired and wireless physical layers are leveraged (dual mesh), gaining the strengths of
each and avoiding the weaknesses. All INSTEON devices are true peers. Every device
on the network repeats every message heard, utilizing a simulcast methodology. All
messages are confirmed, and every message is resent if an acknowledgement is not
received. If available, both powerline and RF networks are used, with the powerline data
being the default if unmatched messages arrive simultaneously. There are no masters or
slaves to manage. Reliability is kept high and synchronization kept simple through use
of short messages – an entire message cycle is under 0.04 seconds.
Figure 1
Continued on page 20
April 2006 / 19
Some of the technical specifications of INSTEON include:
n Dual mesh: RF and powerline
n Peer-to-peer mesh
n Devices are repeaters
n Messages acknowledged, with automatic retry
n 13, 165 bits/second data rate
n 10 word standard and 24 word extended (with user data) messages, over 16M
unique device IDs and 65K commands
n Powerline: 131.65 kHz BPSK
n RF: 902 to 924 MHz FSK, 150 foot line-of-sight range
But, wait a second. What if you want to control everything with a PC, PDA, or cell phone?
With INSTEON, that kind of control is an option, but not a requirement. That simplicity
frees up the developer to pour time and energy into the actual device, instead of getting
sidetracked trying to hypothesize and design around a location in a network hierarchy
where that device should go.
SmartLabs developed INSTEON as virtually an open source platform to ensure that
developers are properly equipped to fully leverage the INSTEON technology into their
projects. There are more than 500 manufacturers and developers currently working
with INSTEON, and it is already being innovatively applied in ways SmartLabs did not
even imagine. Freedom breeds creativity. Creativity builds solutions. Solutions make life
better. And really, isn’t that what technology is supposed to be all about?
By now the cynics are thinking, great technology, but how much to get involved?
A complete developer’s kit is just $99; kits contain two powerline modules, one
power control, one lamp dimmer, with a USB or serial connection to a programming
host, and a software development kit. SmartLabs aims to get the best technology to
the best minds as easily and as painlessly as possible. The low cost also allows the
startups operating out of windowless garages the same access to INSTEON as their
multinational competitors.
Developers will also find support and a developer forum on INSTEON.net hosted by
the INSTEON Alliance, a focused community for developers to incorporate the INSTEON
standard into their products. Additionally, the INSTEON Alliance will host its inaugural
INSTEON Development and Technology Conference May 2 at the Santa Clara Convention
Center.
Consumers are ready to take control of their homes. INSTEON is here and ready to go
to work. The only question left is, how? It’s a question developers will be answering
– brilliantly – for a long time.
Dan Cregg, now CTO of SmartLabs, began his tenure there as director of engineering
and product development in 1997 when SmartLabs acquired SmartLinc, a company
he cofounded. Dan also founded and was president of HomeRun Automation, which
was purchased by SmartLinc in 1997. Dan has also held engineering positions at
McDonnell-Douglas, SVG Thermco, and Universal Electronics.
HomeRemote wireless home automation system. It provides Web-based or
SMS-based monitoring and control of
wireless sensors and devices based on a
broadband Ethernet to ZigBee gateway.
The touch of your finger
Several companies are going after a simplified home automation interface with
a unified touch screen and background
application and driver software to bring
interfaces from several systems together.
Casaworks, www.casaworks.com, brought
their Cielo home management system,
depicted in Figure 5, which integrates
their Studio software with a variety of
interfaces to home systems. Scenes can be
programmed to establish a set of controls
– lighting, audio, temperature, and window coverings, based on user input, programmed time, or other event.
Figure 5
Convergent Living, www.convergentliving.
com, shared with us their central home
remote concept called the Companion in
a separate interview before CES. Based
on Linux and using Macromedia flash and
Firefox for the user interface, subsystems
are integrated into a master control interface on a 8.4" color LCD touch screen.
Most systems are integrated via Ethernet
connections.
Home Automation, Inc. (HAI), www.
homeauto.com, introduced the OmniTouch
with Video (Figure 6), a color touch screen
bringing control of lighting, temperature,
security, and multiroom audio systems
together with the ability to display digital
video of up to six cameras.
Russound, www.russound.com, introduced
their UNO-TS2D, a desktop version of
their wall-mounted color touch screen for
control of multiroom audo/video systems.
For more information, contact Dan at:
SmartLabs, Inc.
16542 Millikan Avenue • Irvine, CA 92606
Tel: 949-221-9200 ext. 147
E-mail: [email protected] • Website: www.INSTEON.net
Figure 6
20 / April 2006
Xantech, www.xantech.com, demonstrated their SPLCD64V LCD touch screen controller, with a companion XTR39 touch screen remote. These units combine functions of a
myriad of home entertainment devices into single units with a graphical interface.
On the go
AquaSonus, www.aquasonus.com, showed an interesting
device (Figure 7), a pool security hydrophone designed to
alert swimming pool owners to the possibility of a submerged
large body, such as a child or pet. The device installs at the
pool edge, with a hydrophone protruding under the water.
It uses proprietary DSP algorithms to analyze the pool
and differentiate between the routine sounds of the pump,
cleaning equipment, rain, debris, and an actual intrusion of
concern. It transmits information wirelessly to a monitor
inside the home, showing status and emitting an alarm on a
detected intrusion.
Eleksen, www.fabrickeyboard.com, displayed their Bluetooth
keyboard (Figure 8) composed of fabric. Intended to be
portable or designed directly into clothing or other applications where flexibility is needed, it offers a full-size
keyboard where a rigid design would probably not fit.
Figure 7
GameRunner, www.fpgamerunner.com, showed their innovative controller for video games, a treadmill with game
controls mounted on a set of handlebars. It breaks the
notion that the game experience requires being seated
Figure 8
for hours, and offers quite an experience for first-person
gaming. The game character walks when the user walks on the treadmill, and runs faster
as the user picks up speed.
Realm Systems, www.realmsys.com, showed their iDentity Platform with two key
elements, the iD3 Personal Server and the iD1200 Management Router. The iDentity
Platform enables a robust, secure VPN to be created. Using a fingerprint sensor from
AuthenTec, www.authentec.com, the iD3 acts as a possession token to provide two-factor
authentication with the user’s fingerprint. The iD3 connects to a host PC on a USB port,
and then uses SSL to establish secure communication with the iD1200, which enforces
user- and group-based policies. With a 400 MHz PowerPC processor, up to 128 MB RAM
and 2 GB of storage, an RFID chip, and Bluetooth, the iD3 provides functions such as
encrypted file storage and traceless computing using no application and leaving no data
on the PC host.
Finally, one of the last, more interesting stops we made
was at the OtterBox, www.otterbox.com, booth. OtterBox
manufactures a broad line of waterproof, crushproof,
drop-proof cases and accessories for electronic devices.
Rated to MIL-STD-810F and made from high-impact
polycarbonates and rubber overmolding with compound
latching, they transform an ordinary device into a rugged
one quickly and easily. OtterBoxes, shown in Figure 9,
also offer clear screen membranes, access to device
interfaces, and a range of accessories to enhance the
user’s rugged device experience while still protecting it.
By putting your device in one of these boxes, you gain a
tremendous amount of environment and shock protection
at a fraction of the cost of a fully rugged system. We could
hardly wait to try one of these on the next camping trip.
Changing our way of life
Figure 9
The range of consumer electronics devices available today is really impressive. Though
disappointed that more home appliances with embedded electronics weren’t featured
at CES, as it was mostly a multimedia, home entertainment event, we observed how
electronics are showing up in everything from the clothes we wear to the tools we use
throughout the day. Many devices are gaining intelligence in ways invisible to the user.
The human interface is becoming more natural. As usefulness increases, these devices are
becoming part of our way of life. There is still a long way to go, but the signs are clearly
visible in this wave of consumer electronics.
April 2006 / 21
By Srirama Chandra
O
n a large factory floor, several types of real-world signals that
represent various parameters, for example, temperature,
pressure, and voltage, from different locations may be
monitored, logged, processed, and controlled. In such cases, a
Types of communication networks include
Ethernet, wireless link, and fiber optic
link. The type of communication network
depends on the rate of data collection, the
environment, allowable measurement, and
control latency.
The central system communicates
Not only must the client DAQ system
accommodate different communication
interfaces, it also must be able to acquire
and measure different sets of real-world
signals. Srirama examines some of the
issues involved in designing such client
DAQ systems and then proposes a standard architecture for a low-cost client
DAQ system that can easily be customized
on-site.
with the client DAQ systems
Introduction
distributed data acquisition systems network is used. In a distributed
data acquisition system, a centralized server communicates with
client Data Acquisition (DAQ) systems and logs all the acquired
data at a centralized location for further analysis.
Interfacing with different types of networks
and measuring different types of realworld signals must be considered when
designing client DAQ systems, which, with
all of the options, is no easy task. Plus, the
ability to make modifications on-the-fly as
the needs change would be beneficial.
through a communication
network (Figure 1).
Interfacing with different
types of networks
Figure 1
Most distributed systems are installed with
several issues in mind, including expected
traffic, expandability, type of environment,
security, robustness, fail-safe operation,
interoperability, and interference immunity. Some of the types of networks are:
Ethernet, fieldbus (for example, RS-485),
and wireless (IEEE 802.11b, 802.15.1,
802.15.4, and so on). Each type of network
has associated advantages, in fact, so
much so that no single network type can
satisfy all of the monitoring requirements.
Additionally, networks need support for
April 2006 / 23
both revolutionary and evolutionary infrastructures. The approach taken is a hybridnetworking environment in which there
are several types of networks on a factory
floor.
The client DAQ system must be capable
of interfacing with multiple types of networks. If a process moves from one network domain to another, the client DAQ
system must be able to move with it.
Measuring different types of
real-world signals
Client DAQ systems should be able to
interface with different types of real-world
signals that are represented by analog or
digital signals. The analog signals are
generated by sensors or transducers that
convert temperature, pressure, sound, or
light into voltage. The electronic sampling
of analog signals is called Analog to
Digital Conversion (ADC). The digital
output from the ADC should then be
further processed or stored. Some signals
can be generated from high-speed realworld signals (for example, vibration
measurement) and some from much lower
speed signals (for example, power supply
voltage measurement).
Some applications will require client DAQ
systems to generate analog voltages to
drive chart recorders, audio amplifiers,
process actuators, and other devices requiring an analog driving voltage. This is
achieved with the use of Digital to Analog
Converters (DACs). Many data acquisition
boards have both ADCs and DACs.
Client DAQs should also provide Digital
I/O (DIO) lines to operate relays, measure
the speed of a fan-through tachometer,
and turn a system on or off. Typically, digital signal monitoring requires timers,
counters, and frequency measurements.
The digital control signals should be able
to perform frequency generation and pulsewidth modulation, among other functions.
A client DAQ system should be able to interface with any combination of real-world
signals. Further, the system also should be
able to perform some of the signal processing function before transmitting to
the central station for further analysis.
The DIO systems also require timers and
counters.
An on-site, customizable
client DAQ system
The client DAQ system should not only
accommodate any of the standard interfaces on the network side, but also any
combination of data acquisition and control interfaces to real-world signals. This
requires that the client DAQ hardware
provide all types of network interfaces
as well as hardware support for processing all types of acquisition interfaces. Not
surprisingly, such a system will be very
expensive because it needs all types of
network interfaces and data acquisition
interfaces. However, only a small subset
of its functionality will be used at any
installation location.
To reduce the cost of hardware, the proposed client DAQ architecture uses a standard base system that can be customized
depending on the installation location.
Simply plugging in the network interface
module can customize the network side
of the client DAQ system. Plugging in the
required set of data acquisition interface
modules customizes the data acquisition
section of this module. Implementing all
of the required interface and processing
logic within the base module reduces the
cost of these modules. To optimize the
cost of the base module, it is customized
with only the required processing and
interfacing logic necessary for the installed
configuration.
24 / April 2006
The base architecture, once customized
with the necessary plug-in modules both
on the networking and data acquisition
side, communicates with the main central
server and downloads the required logic
for communication module interface,
data acquisition module interface, and the
corresponding processing algorithms.
A client DAQ system
should be able to
interface with any
combination of realworld signals.
One possible on-site, customizable client
DAQ system architecture uses nonvolatile
FPGAs with a soft processor core. To
better understand this architecture, a
brief description of the technologies used
follows.
In-system upgradeable
nonvolatile FPGA
Most FPGAs require an external nonvolatile memory device to store the device
configuration. After power-on, the FPGA
configures itself by downloading the configuration from the external memory
device. Often the external memory device is serial, and it may take an FPGA
hundreds of milliseconds to download the
configuration.
SRAM with on-chip embedded flash
technology provides an advantage over
the traditional FPGA in that it can be reconfigured in microseconds from its
on-chip flash memory, as opposed to
a traditional FPGA taking hundreds of
milliseconds for reconfiguration. In addition, once the FPGA is operational
using the configuration stored in SRAM
memory, the flash configuration can be
updated with a new configuration. This
new configuration can be uploaded into
the SRAM with minimum disruption to
system operation.
Microcontroller soft core
A microcontroller in the FPGA at the
client DAQ provides the ability to process
and analyze data near the collection
point before passing on to the network.
A microcontroller dedicated to each DAQ
function allows the use of a simple and
low-cost 8-bit solution. An open IP core
license, which applies many of the concepts
of the successful open source movement to
programmable logic applications, makes
it even easier to develop appropriate
algorithms.
Client DAQ description
To facilitate customization on both the
networking and the data acquisition
sides, the proposed architecture for the
Figure 2
client DAQ system has two modes of
operation, the preconfiguration mode and
postconfiguration mode. The LatticeXP
nonvolatile FPGA and the LatticeMICO8
(see Figure 2) soft processor core are used
as an example.
In the preconfiguration mode, the base
client DAQ system will have only the logic
required to detect the networking and data
acquisition modules.
In the postconfiguration mode the client
DAQ system is equipped with all of the
required data acquisition interface modules
and the network interface modules plugged in. Additionally, in this mode, the base
module logic has all the necessary interfacing and processing logic.
The transition from the preconfiguration
and postconfiguration modes, also referred to as commissioning, is achieved as
follows:
1. Plug in all necessary networking and
data acquisition modules to the preconfigured base module.
2. The system is connected to the network and is powered on.
3. The onboard DSP processor communicates with the main central server
through the plugged-in network
module and sends the configured
DAQ module information.
4. The main central server then sends
the entire configuration for the nonvolatile FPGA required for operating
with the plugged modules and the
configuration-specific DSP processing
algorithm.
5. The client DAQ system then updates
the FPGA code and the flash memory
with the newly downloaded codes.
6. The client DAQ system is now ready
to perform the data acquisition operation with the site-specific networking
as well as the data acquisition interfaces and is in postconfiguration mode.
Before changing either the networking
interface or the data acquisition interface
of the postconfigured client DAQ system, it should be decommissioned to
preconfiguration mode. The decommissioning process is initiated from the server.
During the decommissioning process,
both the preconfiguration FPGA code
and the preconfiguration DSP processing
algorithm are downloaded through the
networking interface. The client DAQ
system then reprograms the FPGA as
well as the flash memory with the newly
downloaded code to get back into the
preconfiguration mode. Once in the preconfigured mode, both the networking
interface as well as the data acquisition
interface can be changed.
April 2006 / 25
Client DAQ system in
preconfigured mode
Figure 3 shows the block diagram of the
proposed client DAQ system architecture
in the preconfigured mode.
The system is divided into three sections:
On-site customizable communication interface, common base module, and on-site
customizable data acquisition and control
interface.
The common base module section is
equipped with a socket for the network
module, as well as multiple sockets for
data acquisition interface. The start-up program is stored in the flash memory. The
Lattice Power Manager IC performs the
sequencing, reset generation, and supervisory functions. The Lattice ispClock
chip provides all the clocks required by
the board. The LatticeXP FPGA in the
preconfigured mode is programmed with
the following subfunctions:
 Interfaces to all types of networking
modules
 Processor bus interface
 Flash and DDR memory interface
 DAQ module detection hardware
The DSP processor code in the flash
memory enables plug-in module detection
and communication with the central server
system over any of the communication
interfaces.
Configuring the client DAQ system
in preconfiguration mode
The first step in installing a client DAQ
system is to plug in the necessary networking module as well as the sitespecific data acquisition modules. After
all the modules are plugged in, the system
is turned on and connected to the network.
The DSP processor first starts to execute
from the flash memory. The contents of
the flash memory are then transferred into
the DDR memory through the processor
interface section of the FPGA, and from
then on the processor executes from the
DDR memory, freeing the flash memory
for updating. The processor then detects
the plugged-in communication module
as well as the DAQ modules, and sends
a message to the server or the main
controller through the network interface
about the configured status of the client
DAQ module.
The main controller then downloads both
the site-specific processor algorithm as
well as the site-specific FPGA configuration through the communication network.
The downloaded DSP algorithm is then
programmed directly into the flash
memory. Because the LatticeXP FPGA
operates from its SRAM configuration
memory, its nonvolatile configuration
memory is free for updating while the
FPGA is functioning. The DSP processor
then reprograms the nonvolatile on-chip
FPGA configuration memory.
Figure 3
26 / April 2006
With the new code in both the flash
memory as well as in the FPGA nonvolatile
configuration store, the client DAQ system
is now ready to perform the actual sitespecific data acquisition task.
Postconfiguration mode
Figure 4 shows the postconfigured client
DAQ system, which has the following
modules plugged in:
 10/100 Ethernet interface communication module
 Slow ADC and DAC module
 Digital relays/FET control module
 Fast ADC interface module
As noted previously, the LatticeXP FPGA
logic in the postconfiguration mode depends on the network interface as well
as the installed data acquisition modules.
There is a one-to-one relationship between
the networking module interface and the
associated logic within the FPGA. But,
the logic specific to a data acquisition
module is realized by the use of the standard LatticeMICO8 functional block,
and the associated processing function is
implemented using the execution code
loaded into the on-chip embedded RAM.
For every data acquisition module, a copy
of LatticeMICO8 core is instantiated
within the LatticeXP FPGA fabric. The
implementation logic between individual
types of DAQ blocks differs only in the
executable code loaded into the on-chip
Embedded RAM.
Figure 4
April 2006 / 27
S I D EB A R
Functional blocks of the LatticeXP FPGA
 The 10/100 Ethernet interface: This functional block performs
 LatticeMICO8 + slow ADC/DAC interface: This is one of the
instantiations of the LatticeMICO8 soft processor with its algorithm
to periodically acquire the code from the ADC, and to perform
preprocessing operations on each of the acquired samples such as
offset shifting. The LatticeMICO8 processor also compares the input
voltage level with a preset level and interrupts the processor if the
input level exceeds the threshold level. Otherwise, it simply logs the
voltage value in a prefixed location in the memory using the DMA
block. If there is a command from the DSP processor, it picks the
data from the external memory using the DMA and sends the data
to the DAC.
 LatticeMICO8 + timers and counters: The LatticeMICO8 performs
the counter and timer function as determined by the logic interface
function of the digital and other I/O module DAQ.
 LatticeMICO8 + fast ADC interface: This module is coded such that
the data from the ADC is sent directly from the DAQ interface to the
DDR memory using the DMA controller. Once the data transfer is
complete, the DSP processor is interrupted with information about
the status of the transfer and the memory block location to which the
ADC data is transferred. The DSP processor performs all the signal
processing functions directly in the memory, builds the packet, and
transmits it to the main processor.
all of the Media Access Control (MAC) layer functions and enables
the client DAQ system to communicate with the central server
system.
 DDR memory interface: This drives the DDR memory and provides
simple memory interface structure to the rest of the blocks.
 Processor interface: This handles all of the DSP processor bus
interface state machine logic and maps execution and data
memory into DDR.  DMA controller: This is a multichannel DMA controller with a
channel dedicated to transferring data to and from the DDR
memory and the networking interface, each of the data acquisition
module interfaces, and the DSP processor interface.
 LatticeMICO8 instantiation per DAQ module: For every DAQ
module plugged in, a copy of LatticeMICO8 and its executable
code are instantiated within the FPGA. Each of the instantiations
differs only in the processing algorithm loaded into the embedded
memory of the LatticeXP FPGA. The maximum number of DAQ
modules supported determines the size of the FPGA selected.
The data to and from each of the LatticeMICO8 processors and
the memory is handled through the DMA controller that is also
instantiated on the FPGA. A description of the algorithm loaded
into the FPGA’s embedded memory block corresponding to each
of the LatticeMICO8 follows.
The LatticeXP FPGA is now configured
with the following function blocks:
 10/100 Ethernet interface
 DDR memory interface
 Processor interface
 DMA controller
 One instantiation of LatticeMICO8
per DAQ module
Decommissioning
If the equipment needs to be brought back
to preconfiguration status, it can be initiated directly from the central station. For
this, both the flash memory contents as
well as the LatticeXP FPGA configuration are changed to preconfiguration code
using the onboard DSP processor.
Once the programming is complete, the
client DAQ system can be removed from
the network and used anywhere.
Summary
Because the on-site specific configuration
and not a superset of all possible configurations determines the size of the
LatticeXP FPGA, the size of the FPGA
is small. The LatticeMICO8 provides an
easy method to implement the modulespecific algorithm using software. This
28 / April 2006
The flash memory consists of the algorithm specific to the configuration.
enables the module-specific algorithm
implementation without having to refit
the logic within the FPGA. Because
the LatticeMICO8 occupies very few
LUTs (200), multiple instantiation of the
LatticeMICO8 does not require a large
FPGA. Additionally, the LatticeXP FPGA
family offers one of the most economical
solutions at any given FPGA size. All
these factors contribute to reducing the
cost of the implementation.
This architecture enables a single base
module to interface not only with different
DAQ modules, but also with different networks through on-site customization of the
entire system. Because the same hardware
board is used across all locations, process
managers can standardize their entire distributed data acquisition system using
these modules.
The throughput of the system is increased because the LatticeMICO8 processors
offload the main DSP processor from all
the slow peripheral operations as well as
manage the data transfer buffer memory
management. The processor just has to
perform the communication and fast ADC
data processing functions. Consequently, a
slower, less expensive DSP processor will
be satisfactory for a given function.
In conclusion, a low-cost nonvolatile
FPGA such as the LatticeXP used in concert with an open source code soft processor such as the LatticeMICO8 enable
the implementation of a lowest-cost solution client DAQ system that can be used
as a standard solution in a distributed data
acquisition system.
Srirama Chandra is
the marketing manager
for the in-system
programmable mixedsignal products at
Lattice Semiconductor
Corp. Prior to joining
Lattice, Srirama
worked for Vantis
and AMD in sales and applications
and previously was a telecom design
engineer with Indian Telephone
Industries. Chandra received his MS
degree in Electrical Engineering from
Indian Institute of Technology, Madras.
To learn more, contact Srirama at:
Lattice Semiconductor Corp.
5555 N.E. Moore Court • Hillsboro, OR 97124
Tel: 503-268-8634 • Fax: 503-268-8347
Website: www.latticesemi.com
Image fusion:
Shared memory
supports
flexible, multiple
sensor imaging
systems
By Ralph Barrera
Today, demand for high-definition images
is growing rapidly. Unfortunately, simply
displaying more pixels per frame or transmitting frames at a higher rate can’t always
satisfy the need for higher-definition images.
In many cases improving the actual information content of the image being viewed
would help. To accomplish this, a number
of algorithms have been developed to highlight or accent an image by detecting its
edges or to adjust its colors or shades. While
these techniques have greatly increased the
amount of information being displayed, the
need for improvements in image information
continues to grow. One approach involves
using shared memory to facilitate images
derived from multiple sensors.
30 / April 2006
W
e now have the ability to focus multiple sensors on an
object and view that object from different perspectives.
A system that uses sensors sensitive to different wavelengths, for example, combining a visible spectrum sensor with an infrared sensor, adds more information, such as the
thermal signature of the object.
The use of multiple sensors for imaging adds to system complexity. The problem then becomes how to acquire data from
multiple high-speed sensors, combine or fuse the acquired
data in meaningful ways, and present the final image to a user.
Today, some available systems do image fusion, but they tend to
be solutions for a set application with little flexibility or growth
capability. A better approach is to use a shared memory-based
system architecture for image fusion. The use of shared memory
enables a system designer to build an image fusion system that can
accommodate multiple types of sensors and processing elements
while providing an easy growth path when additional sensors or
viewers are required. For example, using shared memory, a system
that starts with two sensors (visual and infrared) can easily grow
when another modality becomes available.
In most systems, data from only two sensors would be combined
at any given time. But, some cases necessitate having more than
two sensors available. Also, occasions may arise when the image
from a visible spectrum camera would be fused with the image
from an infrared sensor. As conditions between the sensor and
the object of interest change it might also be desirable to replace
the visible spectrum camera with one that operates in a low-light
environment. There are other applications when the selection of
sensors would involve visible light, x-ray, ultrasound, and the
images from an MRI, CAT, or PET scan. A typical system with
both multiple sensors and image viewers is shown in Figure 1.
The use of shared memory technology allows multiple sensors
to be connected to the network and called upon as the situation
warrants. Shared memory is dual-port memory that appears on the
host bus as additional host memory. The host reads and writes data
through one port while the network writes data to memory through
to another image without impacting the other
monitors. To display an image, the monitor
references the partition in memory containing
the image desired. Given the nature of a shared
memory network, all data is broadcast around
the network ring. This means that the data
is present within each node simultaneously
and all of the time. To present a new image
the monitor only needs to display a different
section of the shared memory. No additional
network transmissions are required.
Figure 1
a second port. Data written to memory by the host is automatically
transmitted by the hardware to all nodes on the network. Insertion
and transmit/receive FIFOs buffer the data flow to avoid the
data collisions often encountered in standard networks.
Another advantage of shared memory is that it allows sensors
to be added without disturbing the existing network. Using this
approach, each sensor is assigned its own partition of the shared
memory. As new sensors are added they also receive their own
partition. This growth process can continue until all shared memory
is used or until the throughput of the network has been exceeded.
Figure 2 shows one example of a memory assignment that would
support multiple sensors and processing elements, along with an
area assigned for system coordination.
To combine the data from the various sensors a processing element must be added to the network. The type of processing to
be performed will determine
the nature of the element. For
some applications a standard
PC with an x86 processor may
be sufficient, but for high-speed
signal processing the use of
a DSP or an FPGA element
could be employed. Again, the
use of shared memory allows
the network to grow and be
easily modified to meet the
changing requirements of the
application.
Figure 2
An image fusion system using
a shared memory network can
support multiple monitors that
can be focused on the same fused
image or on different images.
One monitor, for example, can
display the raw data from a
single sensor and then switch
Shared memory also provides a benefit to the
data archival system. With all data present
in the archival node’s shared memory, both
the raw data and the fused data can be stored
for future retrieval and analysis. The entire
scenario can be replayed with either the same
merged images or a new set. This enables
the raw data to be retrieved multiple times
without rerunning the procedure. In medical
applications this means a new analysis can
be made without inconveniencing the patient.
In military applications it supports analysis
without the risk associated with redoing the
mission.
For a shared memory network to perform
multiple video image transfers properly an appropriate amount
of bandwidth and memory size is necessary. The Curtiss-Wright
Controls SCRAMNet GT200 offers an ideal platform for shared
memory processing. The GT200 can transfer data at a rate above
210 MBps over a network. The GT200 is offered with a starting
memory size of 128 MB of onboard shared memory.
During a demonstration of a video distribution system with four
video sources and four monitors in May 2005 at the MEECC
conference in Long Beach, California all images were displayed
on each monitor without any frames being dropped. To test the
capabilities of the network an additional throughput load was
added to bring the network up to approximately 90 percent of its
capacity. The test resulted in flawless data transfers without any
loss of video frames. The ability to run a fully loaded network
without data loss is critical for applications where dropped
data might mean bringing patients back for an additional
medical procedure or putting combat personnel at risk to redo a
mission.
Ralph Barrera is product manager for
the SCRAMNet Reflective Shared Memory
product family at Curtiss-Wright Controls
Embedded Computing in Dayton, Ohio.
He has been in the military and aerospace
industry for more than 30 years, holding
positions in engineering and marketing. He
received his PhD at the University of Dayton
and his MS and BS degrees in Electrical
Engineering from The Ohio State University.
Curtiss-Wright Controls Embedded Computing – Dayton
4126 Linden Avenue • Dayton, OH 45432-3068
Tel: 937-252-5601 • Fax: 937-252-1349
Website: www.cwcembedded.com
April 2006 / 31
Bringing
programmability
to the CE market:
Winning design
strategies
The Consumer Electronics (CE) market sets the pace for short
windows of opportunity for market success. Getting your product
out first is a must, and how successful you are will determine your
company’s survival.
CE manufacturers are looking for new, flexible, low-cost, fast development
solutions such as design once, build many products, which was borrowed
from other engineering sectors. This solution involves creating a consumer
electronics platform that can be reprogrammed for multiple finished products
at multiple price points, offering a range of differentiating features and benefits, or even allowing addition of new capabilities as the market tells you what is
most desired. In this article Todd discusses how you can create a winning design
strategy by bringing programmability of hardware to the CE market.
By Todd Scott
CE is the hottest segment in the electronic design world today. Digital televisions, portable
media players, educational toys, residential security, and networking products are all
in a state of continual advancement. In some categories, new generations of products
are introduced nearly every quarter. Windows of opportunity for market success are
shrinking, forcing CE developers to seek and apply new, flexible, low-cost, rapid development solutions.
While Application-Specific Standard Product (ASSP) and Application-Specific Integrated
Circuit (ASIC) logic implementations provide a low-cost, fixed platform for product
design, each has critical drawbacks. Relying on ASSPs reduces potential for differentiation or adding the latest in-demand features, while ASIC development can significantly
jeopardize on-time delivery and is notoriously expensive. Staying ahead of the design
curve requires a product development strategy that enables rapid innovation at a low cost
to ensure a first-mover advantage. Designing one product independently from the next
will not get you there.
What if a product or a whole product line could be developed rapidly while maintaining
the ability to react in weeks to customer feedback and market changes by delivering
differentiated feature sets ahead of the competition? What if features could be tailored
based on a single basic design for multiple users, price points, or market geographies?
By incorporating Programmable Logic
Devices (PLDs) in a platform-based
design, CE designers can set a clear path
toward rapid, low-cost innovation. The
design approach can include ASICs or
ASSPs to implement basic electronic
functions, while using low-cost FPGAs,
CPLDs, or structured ASICs to add the
latest in-demand features in a far shorter
time for consecutive product line releases.
A PLD-based platform design strategy
allows greater product differentiation
for potentially increased margins. The
programmable platform can help get
products to market first and help keep a
brand in the lead. Additionally, PLDs
offer risk reduction. With a strategic
programmable design approach, modifications can occur even after production
begins.
April 2006 / 33
PLDs are not new in CE products. They are found in some of the latest flat-panel
televisions, set-top boxes, DVD recorders, personal media players, electronic educational
toys, and many other consumer products worldwide. They are well suited to nearly any
design where rapid response, design flexibility, and time-to-market crunches occur.
Further, designing strategically with programmable logic can help companies overcome
market hurdles throughout the CE product life cycle (see Figure 1). Whether at concept,
emerging market, aggressive growth, or mature market stage, applying programmability
to a design solves a marketability problem and accelerates product revisions and rapid,
low-cost innovation from prototype through commercial availability.
Figure 1
Combine PLDs with ASICs or ASSPs to win
Competitively priced, differentiated products are critical to any CE company’s survival.
After a new product specification is set, ASIC development can begin. However, ASICs
typically have a development cycle of one year or more. During this critical time, product
requirements may vary due to changing standards, consumer demand, or competitive
actions. Programmable logic provides a low-cost solution to this marketing design
dilemma. PLDs can be programmed late in the development cycle without changing the
basic ASIC or ASSP platform. They allow for innovation without waiting for ASIC respin
cycles (see Figure 2). This helps enable product differentiation, minimize development
time, reduce risk, and provide a true competitive advantage in the race for market share.
34 / April 2006
Figure 2
Being a leader in the CE market
In today’s competitive marketplace, innovation, differentiation, and flexibility in product
development are critical to a company’s success. The following examples illustrate this.
Emerging market
The rapidly evolving home multimedia LAN market uses PLDs to meet the requirements
of greater bandwidth and much higher Quality of Service (QoS). Far different from
residential data LANs, home multimedia LANs need to seamlessly share real-time Audio/
Video (A/V) content. Meeting this challenge with minimal risk requires low-cost solutions
that easily and quickly adapt to changing requirements and rapidly evolving standards.
A typical home multimedia LAN architecture, shown in Figure 3, is based on a central
switch that directs A/V traffic to terminals in each multimedia center or device location
in the home. This LAN must be highly scalable and adaptable to fit an almost endless
number of implementations required in today’s homes.
Figure 3
Terminals use CPLDs to bridge older ASSPs for continual feature evolution, eliminating the
need for board redesign. CPLDs also allow rapid new product introductions to maximize
sales. In the switch, low-cost FPGAs provide a scalable platform enabling high-bandwidth
multimedia content to be moved anywhere within a home network. This scalability allows
a cost-effective range of products or product line, targeting home solutions.
Aggressive growth
The HDTV market is another growth market that relies on programmable logic. For
leadership in a sector experiencing growing consumer interest, company and product
differentiation is essential. In the HDTV market, a range of display sizes and features
provides an obvious path to establishing customer leadership perceptions. A market
that is still looking for continuous product enhancements, as well as increasing retail
price competition, requires a balance between low-cost standard solutions and a unique
intellectual property that differentiates the products.
Low-cost PLDs and structured ASICs are used to implement features complementary to
existing ASSP functionality in high-volume digital displays. PLDs also ease development
Designing strategically with programmable
logic can help companies overcome market
hurdles throughout the CE product life cycle.
April 2006 / 35
and feature enhancement for the newer,
larger displays. Figure 4 illustrates the
development range of HDTVs based on
a single ASSP-based platform. Because
FPGAs are available in a range of device
sizes, this platform design approach
uses a smaller device in a lower-end
42-inch HDTV to improve the picture
quality over the ASSP-only solution. In
the top-line products, such as a 60-inch
display or larger, a large FPGA can significantly improve picture quality and add
differentiated features such as increased input/output ports, multimedia networking, and streamlined user interfaces.
A programmable platform approach provides an HDTV product line with a
range of feature and quality requirements
ahead of any ASSP roadmap and faster
than competitors using an ASSP-only or
ASSP-ASIC development model.
Today’s PLDs – Cost effective
for CE applications
Figure 5
1983
1993
2003
2013
Process
Technology
3 µm
0.8 µm
0.13 µm
32 nm
Equivalent
ASIC Gates
125
14K
960K
9M
Transistor
Count
12K
1,5M
230M
1,500M
Equivalent ASIC
Gates Purchased
for $5
30
375
36K
300K
Like most silicon solutions, the cost of
PLD system implementation has rapidly
decreased while product functionality and
complexity have dramatically increased.
Ten years ago, 52 devices were required
to create the equivalent logic density of
today’s single PLD. While densities have
dramatically increased, cost is declining
by an average of 25 to 30 percent per year
(see Figure 5 and Table 1). Continuous cost
reduction is possible because PLDs use
the most advanced process technologies
and are built to suit more customers than
just a few large-volume opportunities.
from others. In addition, ASSPs are seldom available for the most current functions, so
CE developers must often turn to custom ASICs.
These conditions call for greater flexibility
and agility in product development than
ASSPs and ASICs provide, but relying
on ASSPs exclusively does not allow developers to differentiate their products
ASICs have the advantage of low per-component prices, but the long development times
they require run counter to the need to innovate and quickly offer distinguishing features
in markets saturated with similar products or that are otherwise changing. The high
nonrecurring engineering costs needed for custom ASICs are also a significant barrier for
developers. As a result, CE developers are increasingly turning to low-cost PLDs.
Table 1
CE product developers can take advantage
of low-cost ASSPs for well-established
functions, while relying on programmable
logic to deliver the differentiating capabilities of their product. The time required
to configure the FPGA is in milliseconds
and goes unnoticed by the user. Resulting
FPGA designs use fewer logic resources
by nearly one-third, the cost of which are
only about one-fifth of the typical total bill
of materials, and take advantage of FPGA
reconfigurability. Additionally, the use of
FPGAs and ASSPs reduces manufacturing costs by reducing the number of required components resulting in smaller
board sizes.
Figure 4
36 / April 2006
Many companies have evaluated the
alternatives and concluded that no other
logic component solution achieves either
their cost targets or meets their aggressive
development schedules better than an
FPGA-based design.
The consumer electronics market is forcing product developers to reevaluate existing development models. The traditional
methods of relying on ASSPs or custom
ASICs to achieve the lowest costs are
proving inadequate to the demands for
rapid innovation and increased product
differentiation. Product developers now
can turn to low-cost programmable
logic-based solutions, allowing them to
respond to rapidly changing needs of
consumers. Continuous innovation and
design enhancements will continue this
trend. CE designs not only can afford
the programmable approach, but also demand it.
Todd Scott is senior
director for Altera’s
broadcast and
consumer business
unit in San Jose,
California, where he
manages a marketing
and engineering
team addressing
these two fast-growth
business sectors. He has been with
Altera for nearly five years, and has
served as marketing director with Lattice
Semiconductor and held other marketing
and engineering roles with LSI Logic
and Raytheon Semiconductor. Todd
graduated from Cal Poly with a degree in
Electronic Engineering augmented with
numerous management and marketing
postgraduate courses.
For more information, contact Todd at:
Altera
101 Innovation Drive
San Jose, CA 95134
Tel: 408-544-7768 • Fax: 408-544-8066
Website: www.altera.com/end-markets/
consumer/csm-index.html
April 2006 / 37
Embedded Computer Solutions
For Harsh Environments
-40°C to +85°C Operating Temperature
Five Year Product Availability
Guarantee
ECM401
World’s Fastest
Embedded
Computer Module
CPU, up to
2.8 GHz Pentium 4
(Low power 1.6Ghz and 2.0Ghz
Pentium 4 also available)
4.0”
512Mbytes soldered on-board
DDR memory expandable to
1.5Gbytes using SODIMM socket
SODIMM socket
5.0”
Top view
PCI Bus
COM3 & COM4
Features:
Over 15 years
in business of
designing and
manufacturing
embedded
computer
products for
OEMs and
System
Integrators
Power 12V
x(6) Serial ports
x(4) USB 2.0 ports
x(1) 10/100Base-T
xCompact Flash Socket
xE-IDE supports 2 devices
xVideo I/F (1600X1200, 32 Mb)
xAC’97 2.2 Audio
xLess than 5 seconds boot up
time
x Intelligent thermal management
with independent microcontroller
COM1
COM2
Keyboard, Mouse,
Video, LAN, Speaker
CPU Fan
System Fan
USB 2.0 3-4
USB 2.0 1-2
xPower requirement:
+12V @ 3A (2.0Ghz P4, 256MB)
x Over 200,000 hours MTBF
Bottom view
Compact Flash
Primary EIDE
We can design your Embedded Computer
Board in 30 days.
Time-to-market is very critical to a company's success.
TME has a proven development and manufacturing process that allows
new embedded computer products, using TME's core technologies,
to be developed in 30 days.
OEMs and System Integrators can now bring their products to the
market without compromising cost and features at the expense of time.
Typical Applications
S
S
S
S
S
Robotic
Medical
Avionics
e-Kiosks
Transportation
S
S
S
S
S
On/Off Switch
ECM401 Embedded Computer Module
provides all functions and features of a
high performance computer on a very
small Module.
Embedded Computer Designers can
easily design an I/O board with proper
connectors and form factor that is most
suitable for their applications.
The ECM401 supports up to 1.5Gbytes
DDR memory, 2.8GHz CPU, with built-in
Audio, Video, USB, Network, serial, LPT
interfaces and PCI BUS extension
capability.
.
Military/Aerospace
Industrial Automation
Inventory management
Point Of Sale Terminal
Test & Measurement
Toronto MicroElectronics Inc.
5149 Bradco Boulevard, Mississauga, ON., Canada L4W 2A6
Tel: (905) 625 - 3203 ~ Fax: (905) 625 - 3717
[email protected] ~ www.tme-inc.com
By Sean Riley
D
ecoding a digital video stream is a compute-intensive process necessary in a wide variety of applications from set-top boxes to multiscreen security and surveillance. Whether the encoded bitstream
is MPEG2, MPEG4, H.264, JPEG2000, or some other variant, the incoming pixel rate can be
quite large. Sometimes these obstacles can be overcome with dedicated video decoding hardware,
but what happens when the decoder needs to handle more than one type of encoding scheme?
Compounding the problem, the image resolution often will vary between standard definition and high definition.
Add to this the requirement of decoding multiple streams at once, and it becomes apparent that many hardware
architectures are not up to the job.
Luckily, reconfigurable silicon architectures including FPGAs, CLPDs, ASSPs, and now a new class of devices,
Field Programmable Object Arrays (FPOAs), are ready to meet this challenge. Sean will discuss what FPOAs,
which are high-performance programmable logic devices that are programmed at the object level instead of the
gate level, have to offer the industry.
The capabilities are grouped into Levels
and Profiles, as shown in Table 1. Generally, levels refer to screen resolution and
profiles refer to video quality level. Of
particular interest here are Main Profile
at Main Level, MP@ML, or commonly
called standard definition, and Main Profile
at High Level, MP@HL, commonly called
high definition. Because of the flexibility
of the MPEG2 standard, it is widely
adopted as the standard for DVD players
in a large portion of the world.
Profiles
Simple
Levels
The Moving Picture Experts Group defined the MPEG2 standard as a method
of compressing video and audio data for
transmission across a variety of mediums.
The bandwidth available for each of these
transmission methods varies greatly, so
the MPEG2 standard was designed with
a wide range of video quality options.
These options include resolution of the
image being captured, the frame rate, the
compression of the color components of the
video, and the ability to encode the motion
of objects within the video over time. In
addition, the MPEG2 specification allows
an MPEG2 encoder leeway in dropping
high-frequency components of the video
image without sacrificing the quality of
the video as seen by a human viewer.
Main
High
X
High-1440
X
Main
X
Low
SNR
Spatial
High
X
X
X
X
X
X
X
X
Table 1
Obviously, several multichannel video
streams may need to be decoded in a
typical multimedia decoder. The inherent
flexibility of MPEG2 forces this requirement on anyone developing a playback
device.
The FPOA architecture can be used as
a very high-performance, reconfigurable,
multistream video codec. Because FPOAs
are programmed at the object level
instead of the gate level, they do not
require a lengthy timing closure as in
other architectures. An object can be an
Arithmetic Logic Unit (ALU), Multiply
Accumulator (MAC), or Register File
(RF), and can be interconnected with a
synchronous, 1 GHz programmable connection.
In this implementation, the FPOA is programmed to accept multichannel MPEG2
video data streams, separate them from
each other, decompress the compressed
bitstream, transform the image from its
encoded form through an Inverse Discrete
Cosine Transform (IDCT), scale the video
as necessary, and send the reconstructed
video streams out to external display
drivers.
April 2006 / 39
by Motion Vector and blends them back
into the 8 x 8 blocks coming out of the
IDCT. The Video Scaler performs video
scaling and other video postprocessing.
The rest of the modules manage various
I/O and memory resources internal and
external to the FPOA. Because the FPOA
is operating at 528 MHz, roughly half its
peak operating frequency, it has headroom
to support more than four channels or
faster video bit rates.
The MOA1400D FPOA from MathStar,
pictured in Figure 2, supports 400 ALU,
MAC, and RF objects, and can be clocked
at operating frequencies of 1 GHz, making
it an ideal engine to run a wide variety
of decoders including MPEG2, MPEG4,
H.264, and JPEG2000, depending on the
specific parameters of their decoding algorithms. The MOA1400D is reconfigurable, so updates can be made to the
application in the field.
Figure 1
Figure 1 outlines this particular implementation of an MPEG2 decoder. This
decoder can process four independent
channels of MPEG2 standard definition
(MP@ML) or one channel of MPEG2
high definition in 4:2:0 (MP@HL) or
4:2:2 (HP@ML) format. For purposes of
this discussion, standard definition is assumed to be 720 x 480 resolution video and
high definition is assumed to be 1920 x
1080 resolution video. The device can be
reconfigured in milliseconds to perform
either task.
The Host Interface connects the FPOA
with an external host via a Local Bus
with a raw data rate of 2.5 Gbps. The
compressed video streams are received
by the FPOA on this interface and passed to the Video Buffer Verifier (VBV)
Controller. The VBV Controller manages
the multichannel video frame storage in
memory and flags the channel change on
frame boundaries. The Header Parser and
Control performs any necessary bitstream
parsing of the encoded video data. The
Variable Length Decoder (VLD) culls
information from the video data based on
lookups in the following six tables: macro
block type, macro block address increment,
motion vector, coded block pattern, DC
coefficient, and AC coefficient.
The Motion Vector module determines if
the encoder did any motion estimation;
if so, it rebuilds the encoded motion
vector and calculates the address of the
appropriate reference macro block. This
is a special feature of MPEG2 that allows
40 / April 2006
information to be compressed into a
smaller bitstream than simply compressing
the raw video frame by frame. In parallel,
the Run-Length Expander rebuilds the
correct order of 8 x 8 blocks of pixels.
The MPEG2 encoder further compresses
information by rounding pixel values to
discrete numbers through a process called
quantization. Inverse Quantization (IQ)
reverses this process.
The IDCT performs an inverse discrete
cosine transform on each 8 x 8 block
of pixels, changing the values from 2D
frequency domain back into the spatial domain. The Motion Compensation
module rebuilds each motion-compensated
block from the reference block pointed to
The MPEG2 encoder
further compresses
information by rounding
pixel values to discrete
numbers through
a process called
quantization.
Figure 2
Sean Riley joined
MathStar as vice
president of marketing
in April 2005. He is
responsible for the
planning, definition,
positioning, and marketing of MathStar’s
FPOA product line.
Sean joined MathStar
from Intel Corporation where he spent 13
years in various marketing, engineering,
and general management roles.
To learn more, contact Sean at:
MathStar
19075 N.W. Tanasbourne Drive
Suite 200
Hillsboro, OR 97124
Tel: 503-726-5500
Website: www.mathstar.com
Devices
4DSP
www.4dsp.com
Lattice Semiconductor
LatticeSC
•
Polyphase Filterbank
•
LatticeECP
•
Wideband Digital Down Converter
•
LatticeXP
•
Actel
www.actel.com
•
LSI Logic
ProASIC3
•
ZSPxxx
Cyclone II
www.altera.com
•
HardCopy II
•
SoC
Security
DSP
Comm
ASIC
ispLeverCORE
ProASIC PLUS
Altera
IP Cores
www.latticesemi.com
•
•
Floating Point FFT Core
Structured ASIC
Comm
SoC
Security
DSP
Comm
Company name/
Model number
FPGA
ASIC
IP Cores
ASIC
Structured ASIC
Comm
Company name/
Model number
FPGA
ASIC
•
•
•
www.lsilogic.com
•
VisionSpectrum
•
RapidChip Xtreme2
•
RapidChip Integrator2
•
Stratix II
•
CoreWare
•
Stratix II GX
•
MathStar
www.mathstar.com
AMIRIX Systems
www.amirix.com
Ethernet
www.aspex-semi.com
Linedancer
•
Atmel
AT40K
www.atmel.com
•
ATCxx
Cambridge Consultants
•
www.cambridgeconsultants.com
•
XAP3 Core
ChipX
CX Family
Comtech AHA
www.chipx.com
www.aha.com
DSP Top
Digital Filters
Infineon Technologies
TC1100
•
MIPS32 4Kc/4KEc
•
MIPS32 24K
www.cputech.com
•
www.dsptop.com
•
•
•
MIPS64
•
QinetiQ
www.qinetiq.com
Quixilica Floating Point
•
Quixilica Floating-Point QR Processor Core
•
QuickLogic
www.quicklogic.com
•
RF Engines
www.rfengines.com
DSP Cores for FPGA
•
Quintillium Family
www.mips.com
Pro Series
PolarPro
•
AHA4541
CPU Technology
•
MIPS Technologies
•
Aspex Semiconductor
SOA13D40 FPOA
•
XILINX
www.xilinx.com
Endpoint LogiCORE
VIRTEX-4 FX60
•
VIRTEX-4
www.infineon.com
Spartan
•
•
•
•
•
April 2006 / 41
Avoiding unexpected challenges in
PCI Express core integration
By Tony Sousek and Nick Sgoupis
A
s a fast, versatile, and popular interface, PCI Express (PCIe) is a natural candidate for development
as an IP core for easy reuse. However, more than conformance to the PCIe specification is required to
make such a core a success for designers hoping to minimize how much PCIe technical detail they need to
understand. With this in mind, Tony and Nick evaluate three approaches to PCI core integration.
PCIe integration challenges
Any endpoint controller core implementing the PCIe standard leaves many worries
for designers integrating that core into
their system. Specifically, a core that
stops at providing a Transaction Layer
Packet (TLP) interface might meet the
specification, but designers will be left
on their own when it comes to handling
and processing transaction requests and
generating or processing transaction completions. So much detailed PCIe understanding is required to do this successfully
that the designer starts to lose the benefits
of using a prebuilt core.
A successful TLP interface must perform
several tasks within specific constraints for
both incoming and outgoing requests, and
potentially involves multiple elements in
the designer’s application System-on-Chip
(SoC). Figure 1 shows a typical system
design, with the elements potentially requiring special considerations for correct
PCIe operation listed in red.
For incoming requests, completion packets must be formed with respect to the
max_payload and read completion boundary settings defined in the PCIe configuration space. This means that read
requests bigger than the max_payload
must be answered by several packets, and
all the packets except the last must end
at the read completion boundary.
All fields in the completion TLP must be
correctly encoded, with each packet having
the correct value in its lower address and
byte count fields, as well as having the
proper completion status.
Additional stipulations include:
 Writes to the I/O space require
42 / April 2006
completion, while writes to the
memory space do not.
 The completion address in a
completion packet differs with the
type of request; the lower address
of I/O requests is set to 0, while
that of memory requests depends on
the starting address of the current
completion packet.
 Applications need to correctly report
to the core their problems, such as a
local memory write error or a local
peripheral read/write error, and return
a completion error status in response
to the nonposted requests.
On the outgoing requests side, similar
detailed challenges are normally left to
the PCIe core integrator for both forming
requests correctly and processing completions within tight timing and memory
address constraints.
In forming outgoing requests, it is essential
they not cross the 4 kB boundary, and
nonposted requests must be identified by
a unique tag. The size of read requests is
restricted by the max_read_request_size
parameter stored in the configuration
space in the device control register. Write
requests are similarly restricted by the
max_payload parameter.
Figure 1
Any violations of the packet forming rules
result in the request packet being discarded
and an error being detected at the receiver,
causing a system malfunction.
Completion processing for outgoing requests also takes close attention. Each
completion must be processed by the
order of its tag, but it is difficult to ensure
that multiple outstanding completions are
processed in the correct order. The designer
must define an appropriate completion
time-out limit, which must be greater than
50 µs and less than or equal to 50 ms; the
minimum recommended is 10 ms. Packets
have to arrive for completion in the correct
order, that is, the completion values in the
lower addresses for multiple completion
TLPs must be correct. In addition, both
unsupported request and completer abort
responses from the completer must be
processed.
Figure 2
Ways to make
integration easier
Among the approaches to making PCI
core integration easier, three stand out:
1. Providing detailed examples
2. Developing an efficient proprietary
interface
3. Creating an application interface layer
for standard SoC buses
Through example
As suggested by the Quality for IP Metric
from the VSI Alliance, www.vsia.org, the
deliverables of every core should include
Figure 3
April 2006 / 43
well-documented examples. It would be possible to include with the PCIe core a wellstructured set of effectively designed and explained example implementations to illustrate
ways to handle the technical challenges mentioned.
Unfortunately, relying solely on examples still leaves designers needing to understand
PCIe spec details, and merely provides a set of partial blocks they must still customize for
their own system. Moreover, this approach does little to help designers verify the complete
system, including all the TLP processing.
Through a proprietary interface
One might design an effective and efficient subsystem for processing incoming requests
(a completion controller) and DMA channels able to generate outgoing requests and
process their completions. Such a subsystem could indeed isolate designers from the
PCIe spec TLP details, but then designers must still understand the subsystem’s proprietary interface, and handle verification of the system, including this interface, on their
own. Figure 2 (page 43) depicts a typical SoC architecture using an Application Interface
(AIF) with the PCIe core.
Through an AIF and standard buses
An AIF subsystem as in the previous
approach but designed to work with
industry-standard SoC buses, such as the
Open Core Protocol specification, www.
ocpip.org, or the OpenCores Organization
Wishbone specification, www.opencores.
com, rather than a proprietary bus offers
the best solution for core users. In addition
to using off-the-shelf verification for
the PCIe core itself, there may also be
available verification IP for the selected
standard SoC bus, significantly reducing
the verification burden. Moreover, because
it is likely that the designer already knows
his or her standard SoC bus, working with
a well-designed PCIe application interface
for that bus should be straightforward.
Implementing the AIF
approach
Though it requires the most work of the
three approaches, using an AIF block for
the PCIe endpoint controller core should
be seriously considered. The AIF bridges
the TLP interface and any of several
industry-standard SoC bus interfaces,
handling all the standard data transfers as
well as the more esoteric exceptions and
possible error conditions (see Figure 3
page 43).
The AIF sits between the Endpoint
Controller core and the system into which
the core is being integrated. On the core
side, the AIF implements a complete TLP
interface, handling all the low-level details
mentioned previously.
On the system side, the AIF has a flexible architecture designed for easy adaptation to any of several industry-standard
SoC bus specifications, such as OCP, Wishbone, ARM’s AMBA, www.arm.com, or
IBM’s CoreConnect, www-03.ibm.com/
chips/products/coreconnect/. It includes:
 A Completion Controller with queu-
ed request processing that allows
simultaneous processing of up to two
requests
 A DMA core with up to eight DMA
channels
 An optional Message Controller,
which is planned for future release
CAST, Inc. has a PCIe endpoint controller
core compliant with PCIe base specification
1.0a, including the transaction, data link,
and physical protocol layers.
44 / April 2006
The scalable and flexible core has a modular architecture and a high-performance,
low-latency design. It supports multiple
device link widths to better match the
bandwidth needs of specific applications,
such as x1 or single lane and x4 or four
lane, and offers bidirectional data rates
from 250 MBps for x1 to 1 GBps for x4.
It supports most advanced PCIe capabilities, including message signaled interrupts,
multiple virtual channels, advanced error
reporting, end-to-end cyclic redundancy
check, and power management features.
Multilane versions of the core support
lane reversal and polarity inversion.
The synchronous, latch-free core design
has an AIF layer that implements an asynchronous clock boundary between the core
logic and the user’s application. Standard
bus interfaces such as Wishbone or AMBA
are available, as is a generic interface for
use with any system.
a cofounder of CAST in 1993. In the firm’s early consulting days, he worked on antenna,
elevator, and other systems, and has since focused on refining CAST’s development
environment and tool set as well as designing a variety of IP cores. He has BS and MS
degrees from Columbia University.
To learn more, contact Tony or Nick at:
CAST, Inc.
11 Stonewall Court • Woodcliff Lake, NJ 07677
Tel: 201-391-8300 • Fax: 201-391-8694
E-mail: [email protected] • E-mail: [email protected]
Website: www.cast-inc.com
The core was rigorously verified for compliance with the PCIe specification using
PureSpec PCIe verification IP and the
PureSuite compliance test suite from
Denali, www.denali.com. The core has
been further verified by implementing it in
an FPGA and using the Agilent Protocol
Test Card.
A wise option
Though the PCIe-EP PCIe Endpoint
Controller core from CAST, Inc. is fairly
new to the market, experience to date
with two significant initial customers is
validating the AIF approach. Both are
using the AIF with a Wishbone standard
interface, and their integration efforts are
going smoothly.
Designers selecting a PCIe endpoint controller core would be wise to look for a
capability similar to the AIF, or grapple
with understanding and implementing
the details of the PCIe TLP interface
themselves.
Tony Sousek is a
principal engineer for
CAST, Inc., working
in the company’s
facility in Brno, Czech
Republic. He has
worked on medical,
satellite, security,
and other systems for
several firms in the Czech Republic, and
has performed design engineering for
PCI and other interface IP for CAST
since 2001. He holds an MSEE from the
Technical University of Brno.
Nick Sgoupis is a
senior principal
engineer for CAST, Inc.
working in Putnam
Valley, New York. He
worked on hardware
modeling systems at
Racal-Redac, and was
April 2006 / 45
Publishing™
OpenSystems
OpenSystems
Publishing™
Publishing™
Advertising/Business Office
30233 Jefferson Avenue
St. Clair Shores, MI 48082
Tel: 586-415-6500 n Fax: 586-415-4882
Vice President Marketing & Sales
Patrick Hopper
[email protected]
Business Manager
Karen Layman
Communications Group
Patrick Hopper
Vice President Marketing & Sales
[email protected]
Christine Long
Print and Online Marketing Specialist
[email protected]
Embedded and Test & Analysis Group
Dennis Doyle
Senior Account Manager
[email protected]
Doug Cordier
Account Manager
[email protected]
Barbara Quinlan
Account Manager
[email protected]
Military & Aerospace Group
Tom Varcie
Account Manager
[email protected]
Andrea Stabile
Advertising/Marketing Coordinator
[email protected]
International Sales
Stefan Baginski
European Bureau Chief
[email protected]
Dan Aronovic
Account Manager - Israel
[email protected]
Reprints and PDFs
Call the sales office: 586-415-6500
46 / April 2006

Embedded Computing Design - April 2006

Transcription

Similar documents

88TH RSC HOW TO GUIDE FOR DTS INVITATIONAL

MEASUREMENT TOOLS FOR HYDRAULIC GATE DIAGNOSIS

computer - UniMAP Portal

Skulls Röyksopp Campaign type : Track debut with embedded

and Print - RSC Custom Graphics

Franco Gasperoni [email protected]

new Brochure EN Front v2

SM718 - Silicon Motion

AX-3000 - Uniwell EPOS systems

Sistemi Embedded Introduzione