SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Spectrum Signal Processing (SSPI) -- Ignore unavailable to you. Want to Upgrade?


To: nord who wrote (2455)4/26/1999 8:41:00 PM
From: Danny Hayden  Respond to of 4400
 

April 26, 1999, Issue: 1058
Section: Product Week -- Chips

DSP supports high-end motor control
Stephan Ohr

Norwood, Mass. - Advocates think DSPs will do a better job of calculating
motor acceleration/deceleration curves than microcontrollers. Thus, dedicated
devices such as Analog Devices Inc.'s ADMC-401 are targeting high-end
applications like industrial servo controls, machine tools, robotics and
uninterruptible power supplies.

The ADMC401 integrates a 26-Mips ADSP-2171DSP core and a 12-bit
simultaneous-sampling A/D converter on one chip. The device is among 20
DSPs optimized for specific motor-control applications that ADI intends to
release this year, said Phil Davies, director of the company's Embedded Control
Systems Group.

The device is optimized for speed, precision and control of ac induction motors,
permanent-magnet synchronous motors, brushless dc motors and
switched-reluctance motors in industrial applications that demand the highest
level of processing power. It includes a pipeline 12-bit A/D converter with a
multiplexed eight-channel input. The pipeline flash converts in less than 2
microseconds. Signal-to-noise ratio is greater than 70 dB.

Other on-chip peripherals include a separate encoder interface unit with
programmable input filtering (for reading optical encoder disks on the motor
shaft) and a 16-bit, three-phase pulse-width modulator. Separate power
transistors will amplify the PWM output to drive the motor coils.

There are also 12 lines of programmable digital I/O, two auxiliary PWM outputs,
a 16-bit watchdog timer, two 16-bit interval timers and a programmable interrupt
controller that prioritizes peripheral interrupts.

The DSP core is an ADSP-2171 fixed-point version, code-compatible with the
company's ADSP-21xx general-purpose DSP family and the ADMC3xx family
of embedded DSP motor controllers. The ADMC401 includes on-chip program
and data memory in addition to an external program and data bus for adding
extra memory or other peripherals as needed.

Using algebraic C-language-like constructs, Analog Devices' fixed-point DSP
cores

allow users to easily develop programs and applications, decreasing overall
time-to-market. A software development kit-the
ADMC401-ADVEVALKIT-sells for $395 and includes a Windows-based
motion-control debugger.

Samples and advanced evaluation kits are available now. The ADMC401
comes in a 144-pin thin quad flat pack and is priced at $15 in high volumes.

Call (781) 937-1679

www.analog.com/motorcontrol



To: nord who wrote (2455)4/26/1999 8:53:00 PM
From: Danny Hayden  Respond to of 4400
 
Boards march on, in lockstep with DSPs
David Lieberman

As DSP chip performance reaches monster proportions and board makers pack
multiples of these processors onto their products, there's a call for DSP board
architectures that can keep the critters suitably fed and effectively
synchronized. Recent days have seen stepped-up activity to turn the megaflops
on a board into useful work.

"One thing about board-level design is that you're always fighting a battle to add
more features in the square inches you've got," said Rob Shadduck, executive
vice president of Blue Wave Systems Inc. (Carrollton, Texas). At bottom, he
said, "All features will boil down to how well you maximize data flow around the
board."

Mercury Computer Systems (Chelmsford, Mass.) made a push late last year to
up the throughput for boards compatible with its ANSI-standard Raceway
interconnect to make it "a bigger and better topology," said Barry Eisenstein,
vice president of advanced technology at Mercury. The second generation of
the interconnect, dubbed Race++, represents "a managed evolution," he said,
which increases not just performance but also connectivity and scalability.

Race++ boosts the frequency of the interconnect from 40 to 66 MHz and
increases the number of ports provided in one crossbar ASIC from six to eight.
Point-to-point capabilities rise from 160 to 264 Mbytes/second, while aggregate
bandwidth goes from 480 Mbytes/s to 1 Gbyte/s. And while Race can scale to
handle about 1,000 processors, Race++ takes on upwards of 4,000.

Among the more finicky details of the architectural enhancements, Race
provides the hardware for two nodes to implement adaptive routing for finding
the least-congested paths from one point to another. Race++ supports adaptive
routing for all nodes.

Further, Eisenstein said, while sources and destinations on a Race fabric may be
CPUs, DSPs, specialty processors, local memory, shared memory buffers and
various bus address spaces, Race++ "extends the concept to encompass the
crossbar ASIC itself." The benefit, he said, "is that it adds handles for users to
control adaptive routing and new ways to reconfigure routing in real-time."

Optimizing data flow around and between DSP boards, of course, requires
attention to memory and I/O architectures and interprocessor communications.
According to a spokesman for Alacron (Nashua, N.H.), the efficiency of a
design based on multiple Sharc DSPs from Analog Devices Inc. "is critically
dependent upon system architecture, and architectures commonly employed in
multiprocessor Sharc designs do not take full advantage of the Sharc's
capabilities." To perform efficiently, he said, "a system's architecture must
support the parallel-programming model that is best suited to a given application,
and provide sufficient memory bandwidth to permit the Sharc processors to
function as close to optimally as possible."

The company recently committed to applying its dual-ported local-memory
architecture to Analog Devices' latest 200-MHz ADSP-21160 Sharc DSPs.
"These new processors will provide developers with up to five times the
performance per processor of earlier models," said the spokesman.

Alacron's memory architecture supports single- and multiple-instruction-set
programming models and provides all Sharc processors with "full memory
bandwidth," said the spokesman, "without contention for global memory." The
result is "full scalability for applications, whether the design calls for two or eight
Sharcs or 24, without the use of exotic memory architectures."

Historically, multiple Sharcs and C40 DSPs from Texas Instruments Inc. have
been sewn together with those chips' native ports: "link" ports and "comm" ports,
respectively. Late last year, for example, Analogic Corp. (Wakefield, Mass.)
launched a 3U CompactPCI board, the CPCI-DSP-II, with two Sharcs linked to
each other and the outside world by 40-Mbyte/s link ports. "Top performance
can be achieved by establishing a direct data interface through each board's
DSP link port," said a company spokesman.

For high-end applications using many DSPs, however, the native ports are fast
becoming inadequate, according to some sources. "Those paths are not
nowadays of sufficient bandwidth for high-end applications," said Blue Wave's
Shadduck. "It's a rough rule of thumb that if you've got 1 Gflops of processing
power, you're probably going to need to move data around on the order of 100
to 200 Mbytes/s, and those links are not up to those rates."

Late last year, however, BittWare Research Systems (Concord, N.H.) launched
a board up in the 720-Mflops range that relies on a novel use of Sharc link ports.
The Goblin, a 6U CompactPCI board with up to seven ADSP-2106x Sharcs,
has an asymmetrical multiprocessing model and a highly scalable hypercube-like
architecture. The scheme boasts a 560-Mbyte/s memory bandwidth and starts
at $8,495.

The Goblin designates one master DSP and up to six slaves, said Gordon
Leeuwrik, vice president of engineering, with each slave DSP linked to the
master and to its three "nearest neighbor" slaves. While the slaves gang up on
the processing tasks at hand, the master handles the bus interface and assorted
housekeeping chores.

The nearest-neighbor configuration allows any DSP to talk to any other DSP on
the board "in two hops maximum," Leeuwrik said-or four hops between DSPs in
a multiboard configuration.

Elsewhere in the Sharc world, Spectrum Signal Processing (Burnaby, B.C.)
provided a ringing endorsement of the PMC (PCI Mezzanine Card) last month,
announcing a PMC board called Aida with four Sharc 21060 DSPs in residence.
It starts at $6,050 and boasts "up to 332-Mbyte/s off-board communications."

Graeme Harfman, the Sharc product-line manager, said Spectrum is pitching the
board in three ways: as a DSP coprocessor for a general-purpose single-board
computer; as a vehicle for expanding the link ports on a system DSP board; and
as "a low-latency, deterministic data-communications gateway" from an SBC to
a DSP subsystem.

"Traditionally, parallel-processing developers relied on backplane
communications and were faced with a relatively slow bandwidth between their
run-time single-board computer and their multiboard Sharc system," Harfman
said.

Over in TI land, the current-generation C6x DSPs "have no comm ports," said
Blue Wave's Shadduck, "so you need to provide another means of throwing data
at the processors, some high-speed data path that requires minimal processor
intervention." The route taken by Blue Wave for a quad-DSP VME board
introduced earlier this year is a crossbar switch.

The crossbar on the Model VME/C6420 board links up to four TMS320C6201
fixed-point DSPs or TMS320C6701 floating-point DSPs, as well as the board's
VMEbus interface, P2 interface and on-board PMC site. It allows up to five
200-Mbyte/s transfers to occur simultaneously: four on board, one between
boards.

The crossbar is dynamically reconfigurable and all of the routing is done in
hardware, Shadduck said. The result, he said, is "an immense saving in software
overhead." The board uses a Motorola MPC860 as a supervisory processor.
The starting price is $14,000.

Ixthos Inc. (Leesburg, Va.), a wholly owned subsidiary of DY 4 Systems Inc.
(Kanata, Ontario), launched a new DSP board architecture early this year
called Champ, starting out with a four-DSP model. First to roll was the
Champ-C6, which has either four 167-MHz TMS320C6701s or four 200-MHz
TMS320C6201s, delivering 4 Gflops or 6,400 Mips. Prices start at $15,900.

The Champ-more properly, the Common Heterogeneous Architecture for
Multiprocessing-relies on a 66-MHz, 64-bit PCI backbone bus and the
company's own IXStar DSP/PCI interface ASIC. "The Champ architecture
organizes the processing resource as two clusters of DSP processor elements,"
said Mark Alexander, product-support manager at Ixthos.

Both processors in a cluster have their own 32-bit PCI path to a common
IXStar, and that ASIC gives each cluster dedicated access to a 66-MHz, 64-bit
PMC expansion site. Clusters are isolated from each other and from the board's
supervisory PowerPC microprocessor by PCI/PCI bridges, which "allow
concurrent data movement and make each processing cluster's I/O operations
independent of other on-board data-transfer operations," Alexander said. "The
internal PCI bus allows up to three independent data paths, each with peak
transfer rates of 528 Mbytes/s."

Pentek Inc. (Upper Saddle River, N.J.), on the other hand, eschewed PMC for
the I/O on its Model 429x, a quad-C6201 or quad-6701 VMEbus board
announced late last year. Instead it tapped a homegrown I/O scheme called
VIM (VelociTI Interface Modules), which gives every processor its own
dedicated mezzanine site. (VelociTI is TI's VLIW DSP architecture,
implemented in the C6x family.)

Pentek already supports three to four different mezzanine buses for I/O, but a
new bus was absolutely required to keep up with the DSPs, said company vice
president Rodger Hosking. The VIM scheme is "tailored for maximum I/O
throughput and fully buffered with synchronous FIFOs to minimize processor
overhead," he said. It provides 400 Mbytes/s of I/O bandwidth for each DSP on
board, as well as two buffered 50-Mbit/s serial ports and a 32-bit data-address
port for status and control. Aggregate I/O bandwidth on the four-DSP board is
1.6 Gbytes/s. A CompactPCI follow-on is expected.

The company has been steadily expanding the slate of VIM modules to fill the
expansion sites on the Model 429X, having entered the new year with three
choices in its stable: a narrowband digital receiver; an A/D converter; and a
C40 comm-port adapter. At the start of this year, Pentek introduced its fourth,
fifth and sixth VIM boards, with hopes of having an even dozen available by
year's end. These were the $2,000 Model 6220 Raceway interface, the $995
Model 6226 FPDP (front-panel data port) adapter and the Model 6216, a $4,000
multifunction VIM module containing two wideband digital down converters,
two amplifiers and two 65-MHz, 12-bit A/D converters.

Both Race and FPDP "provide direct board-to-board connection between
processor boards, high-speed peripherals and fast memory boards," Hosking
said, but he noted that there are differences between these two ANSI
standards.

"Race is a high-speed synchronous backplane fabric that provides multiple,
simultaneous 160-Mbyte/s data channels between boards," he said. "For
example, in a 12-board system, an aggregate transfer rate of up to 1 Gbyte/s is
achieved."

As for FPDP, "it's a front-panel ribbon-cable interface capable of delivering
data at sustained rates of 160 Mbytes/s. For example, in a four-board system,
an aggregate transfer rate of 1.28 Gbytes/s is achieved." The FPDP is
"particularly useful for implementing pipelined, star or mesh data-flow schemes
across multiple C6x boards," said Hosking.

The Model 6216 combo VIM board is squarely aimed at software radio
applications, serving as "a complete front end" on a DSP board, according to
Hosking. It "allows system engineers to perform real-time DSP processing of
25-MHz digital-receiver signals for the first time."

With two of these boards on a DSP baseboard, "four complete software radio
receiver channels including the digitizer, digital receiver and DSP functions can
all be handled in a single VME slot," he said, "dramatically reducing system
space, power and cost."

Elsewhere in TI-based DSP boards, Hunt Engineering (U.K.) Ltd. announced a
modular C6x packaging and communications scheme late last year called Heron
(Hunt Engineering Resource Node) that it hopes will repeat the success of TI's
modular TIM-40 scheme for C4x-era DSPs. In the United States, Traquair
Data Systems Inc. (Ithaca, N.Y.) has adopted Heron for its own products.

As with TIM-40, Heron mezzanine modules may contain a DSP and memory,
some type of I/O resource or a combination of the two, with the number of
modules that can fit on a carrier board depending on the carrier's form factor.
Traquair's first launch for the architecture was the HEPC8, a $3,400 PCI
carrier board that accommodates four Heron modules. The company also plans
to introduce VMEbus and CompactPCI carrier boards this year, as well as
several Heron modules, including a digital-camera interface and a multichannel
A/D board.

The HEPC8 contains a local implementation of Heron's communications
scheme, dubbed Heart, which has the benefits of high bandwidth, low latency,
determinism and flexibility, according to Traquair president Steve Bradshaw.
The scheme supports multiple simultaneous transfers at 400 Mbytes/s each,
with links for point-to-point, multicast and broadcast operations dynamically
established by software. A follow-on PCI carrier board with a global Heart
implementation, the HEPC9, will be introduced sometime this year.

---

COMPANY CONTACTS

Alacron

(603) 891-2750

www.alacron.com

EETInfo No. 611

---

Analogic

(800) 446-8936

www.analogic.com/Level4/CompactPCI%20summary%20sheet.html

EETInfo No. 612

---

BittWare Research Systems

(603) 226-0404

www.bittware.com

EETInfo No. 613

---

Blue Wave Systems Inc.

(972) 277-4600

www.bluews.com

EETInfo No. 614

---

Ixthos Inc.

(703) 779-7800

www.ixthos.com

EETInfo No.615

---

Mercury Computer

Systems Inc.

(978) 256-1300

www.mc.com/products.

EETInfo No. 616

---

Pentek Inc.

(201) 818-5900

www.pentek.com

EETInfo No. 617

---

Spectrum Signal Processing

(604) 421-5422

www.spectrumsignal.com

EETInfo No.618

---

Traquair Data

Systems Inc.

(607) 266-6000

www.traquair.com

EETInfo No. 619



To: nord who wrote (2455)4/27/1999 12:03:00 AM
From: Danny Hayden  Respond to of 4400
 

April 26, 1999, Issue: 1058
Section: Signals -- Focus: DSP Trends, Applications

Environment counts for efficient code
Phil Radtke, Software Marketing Manager, and Arda Erol, Development Engineer,
Spectrum Signal Processing Inc., Burnaby, B.C.

Over the past half-decade, fixed-function hardware has been replaced
increasingly by flexible DSP platforms. Concurrently, DSP silicon's
performance, capabilities and complexity have dramatically increased, resulting
in the acceptance of DSP technology into markets where it had previously been
shunned. Because of those trends, many designers new to DSP have had to
learn how to use new development tools while under pressure to meet
aggressive time-to-market deadlines.

Many applications that were solely in the realm of fixed-function hardware are
now becoming deployable with software on today's higher-performance
programmable DSPs, leading to a shift of the critical path for new-product
release from hardware to software. At the same time, the widening number of
choices for DSP silicon has made it difficult for designers to learn and reuse a
single set of development methodologies. DSP developers are looking for
development environments to relieve time-to-market pressures.

The typical DSP software project goes through a number of development and
debug stages, with each stage increasing in complexity and development time.
The development path for most DSP software begins on the host platform, with
significant up-front effort spent on the simulation and testing of algorithm
theories. The next step is to transition the working simulation from the host
environment to the target hardware. That step forces the developer to learn the
target hardware and to restructure the code to match the DSP's architecture.
Once this hurdle is passed, the developer needs to ensure the DSP's efficient
utilization through proper scheduling of DSP tasks and efficient communication
between software modules.

If the processing power of one DSP is not sufficient, the developer must move
to a multiprocessor environment and deal with interprocessor-and perhaps
interboard-communication issues. Once all of this is complete, and the
application is functioning correctly, the developer moves to the final stages of
project wrapup and verification.

All of those stages take time, and the time between stages increases in tandem
with the complexity of the system. Essentially, developers need tools to shorten
the time between stages.

System-level approach

System-level software-development tools can significantly reduce
time-to-market. For example, if the software environment helps the developer
control and download code to the hardware, the step from simulation to
prototyping on the target is simplified and shortened. With integrated tools that
enable the developer to communicate between DSPs, the development steps
from single processing to multiprocessing can be reduced.

However, different tools and system-level visualization aids are required at
every step.

A software-development environment integrated with the development process
and the platform could lead to significant reductions in overall development time.
While the individual stages will probably never be eliminated, the time between
stages can be greatly reduced.

Typically, DSPs are used in applications that require extremely high
performance. Therefore, the efficiency of the software and integration of all
relevant components are invariably key in achieving the performance needed for
real-time applications. The system-level software environment needs to be
modular, must expose the performance of the underlying DSP hardware and
must let the developers select the components or features they want in their
system.

For example, if one does not need virtual communications between DSP nodes,
the code to support virtual channels should not be downloaded to the target. The
ideal environment is one that brings together the software tools needed to
shorten the time between project milestones throughout the entire development
cycle without forcing design decisions.

Consider the software implementation of a V.34/V.42 modem as an example of
the multitasking iteration. There are four main components: the analog data
pump, the digital data pump, the data correction and the data compression. The
two data-pump components are time-critical, real-time modules that need to be
running within strict timing constraints in order to keep a connection with a
remote modem.

On the other hand, the data-correction and the data-compression modules are
non-time-critical. If they cannot meet their timing requirements, the connection
to the remote modem will not be dropped, and the only side-effect is a loss in
data-transfer speed. That is not nearly as severe as losing the connection when
the data pumps cannot meet their timing requirements.

Module debug

Since each module performs a unique function with unique timing constraints,
each module in the system needs a different debugging approach during
development. In fact, each bug requires a different debugging approach. Using
traditional streaming I/O approaches-file I/O, print-to-file-requires the developer
to make modifications to the code each time he wants to log a different variable
or buffer in the system. But such modifications to highly optimized sections of
code can introduce bugs that make it even more difficult to find the original bug.

Thus, a single bug can cost the developer days and even weeks. Debugging
DSP algorithms is a non-trivial task and one that most people underestimate.
More sophisticated graphical tools would make the tracking and solution of
those problems simpler.

A proper development environment scales with the application, single-DSP
systems to multi-DSP systems, and can simplify debugging by providing
powerful and easy-to-use debugging support. For example, support for real-time
or post mortem trace of run-time variables that don't require code modification
saves time and prevents many potential problems. Then the developer can focus
on the real problem rather than on how to log or trace variables. When such
tools are used, developers do not need as much real-time systems experience.

Once the software modules are complete, software components may have to be
moved to other DSPs in the system to spread the processing load over a larger
network. This would be necessary if a single DSP were not fast enough to
perform the modem functions or if the user wanted to run multiple modems in
the system. If the development environment supports the easy relocation of
algorithms or algorithm blocks to multiple processors, the user does not need to
know anything about the multiprocessor system.

Nevertheless, in a multiprocessing environment, the debugging problems become
even more complex. The developer needs to not only understand the interaction
of software modules on one DSP, but also to understand the interaction of
software modules such as timing, synchronization and message handling
between DSPs. The most efficient way to solve those multiprocessor problems
is to visualize the DSP network and track the interaction of the software
between the network nodes.

Even when the software on each DSP has been debugged and highly optimized,
significant performance trade-offs and optimizations can still be made by looking
at the DSP network from a system-level perspective. The Apex Trace tool
from Spectrum Signal Processing is one example of a debugging tool that can be
used to make intelligent programming trade-offs across a network of DSPs.

The trace tool is a software logic analyzer that can be customized to trace
user-defined interactions. It is typically used by developers to shorten the time it
takes to debug multiprocessor applications.

A common scenario for system-level optimizations occurs in systems where
there are multiple DSPs waiting for data to perform time-critical operations. For
example, assume that a developer has just finished programming a system
where processor 0 is interacting with another portion of the system and farms
out data to two other DSPs (processors 1 and 2) in the system. The task of
processors 1 and 2 is to manipulate the data and transfer back to processor 0 a
new data sequence. Such hierarchical relationships are typical in multiprocessor
systems.

After the code has been debugged and optimized for each DSP, the developer
benchmarks the system and discovers the performance of the system is not as
good as expected. Where does one start to improve the system's efficiency?
The first step, using the trace tool, is to take a snapshot of the system and zoom
in on the possible bottlenecks.

Tracing bottlenecks

Using a trace tool, the developer might see that processors 1 and 2, in this area
of the program, are spending most of their time waiting for data from processor
0. This would show up in the "channel in" and "channel out" trace lines for
processors 1 and processor 2. The developer may also notice that processor 0 is
spending most of its time waiting for data from the host system. The solution is
simple: remove the host-interaction bottleneck and this will eliminate the idle
times associated with processors 1 and 2. Simply by removing this bottleneck,
the utilization of processors 1 and 2 is dramatically increased, making the entire
system more efficient.

This is an example of the comprehensive environment the DSP industry needs
to reduce the time-to-productivity and the time-to-market demands of today's
increasingly complex applications.

Software tools in the DSP industry have traditionally lagged behind the tools in
other industries because of the DSP market's immaturity and the deeply
embedded nature of the technology. However, this situation is changing. DSPs
are becoming accepted in new and increasingly complex application areas,
fueling the need for development tools that more closely match the system-level,
visualization environments found in other industries.

Because DSPs are employed in application areas that demand the highest
performance available, it is often necessary to have arrays of DSPs to meet
those demands. In such multiprocessing environments, it is important to have a
tight coupling between the development environment and the hardware so that
the most efficient code and the proper system-level trade-offs are made in an
organized and timely manner.