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 : EZchip Semiconductor
EZCH 25.490.0%Feb 23 4:00 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Clappy who wrote (36)8/17/2000 7:00:17 PM
From: Clappy  Read Replies (1) of 2675
 
...and yet another article dated 8/11/00.

eet.com

New wave of silicon embraces APIs,
classifiers

By Craig Matsumoto
EE Times
(08/11/00, 5:04 p.m. EST)

SAN JOSE, Calif. — Even as network processor vendors turn their gaze
from hardware to software and APIs, a second wave of chips tailored
for the toughest packet-processing jobs is emerging. Coming on
strong are coprocessors designed to tackle what has turned out to be
the most computationally difficult step in packet processing:
classification.

Two companies — EZChip and PixelFusion — this week disclosed
additional details of their plans to use embedded DRAM in integrated
devices that both process and forward Internet packet data. The
devices, described at the Network Processors Conference here,
consist of single-chip processors targeting up to OC-192
(10-Gbit/second) speeds.

PixelFusion Ltd. (Bristol, England), which began life as a
graphics-accelerator shop, claims to have packed onto its
yet-unreleased Fuzion 150 chip 1,536 processors, each with 2 kbytes
of memory accessed through four Rambus DRAM channels. The result
is single-chip processing that can handle routing at Layers 5 through
7 of the Open Systems Interconnect protocol stack, the company
said.

For its part, EZchip Technologies Ltd. (Migdal Haemek, Israel)
revealed a few more details of its chip, being developed to handle all
aspects of packet processing and forwarding for OC-192 traffic. The
parallel-pipelined device relies on heavy amounts of embedded DRAM
— each of the chip's 32 search engines consists of four memory
cores, each working on a 256-bit bus. EZchip also uses proprietary
search algorithms that require one-third the number of memory
accesses as a normal algorithm, said president Eli Fruchter.

Devices like these are still in the planning stages, but much of the
first round of packet-processing silicon is getting prepped to ramp up
for shipping. With their hardware architectures established, most of
the vendors that gathered here at this week's confab have turned
their attention to marshaling support for application programming
interfaces, hoping to establish some industry standards.

Backers of the Common Processor Interface (CPIX) breathed a
collective sigh of relief when holdout Intel Corp. announced it was
joining the cross-company coalition. Indeed, most of the industry has
rallied behind CPIX and the sister Common Switch Interface (CSIX),
which would set certain API standards among network processors. But
at the Networld+Interop show in May, Intel scratched its fingernail
across the industry's chalkboard by suggesting its own APIs were
superior. Last week it became the last of the net processor firms to
join CPIX.

Elsewhere on the software front, Curtis Schwaderer, director of
network technologies for Microware Systems Corp. (Des Moines,
Iowa), made the case for creating a network processor operating
system — essentially a real-time OS optimized for a communications
framework. This so-called "NPOS" would have to be component-based,
Schwaderer said, to allow dynamic addition or removal of code. It
would also have to meet the reliability, security and fault tolerance
required in the telecom world.

Software holds "fabulous start-up opportunities [in network
processing], because nobody's really nailed it yet," said John Kennedy,
a director of marketing with MMC Networks Inc., the Sunnyvale,
Calif.-based net processor vendor. "Follow the evolution of the DSP
industry, in terms of software, and that's where the networking
industry is going to go."

Much has been made over whether the network processor will
combine the control plane and data plane. That kind of integration
tends to happen at the lower end, said Gary Lidington, vice president
of business development for the C-Port division of Motorola Inc.

Even if the two are separated, they can't be completely divorced,
said John Fryer, vice president of marketing for the NetPlane Systems
division of Conexant Systems Inc. "The slow-path software interface
has to run at about 20 percent line speed," he said. "The richness of
the API you get between the control plane and the data plane is
going to be key to your success."

Systems considerations come into play as well, because software is
getting increasingly distributed, Fryer said. "Hardware-software
interaction has always been the stumbling block" for systems vendors,
he maintained — more so than the operating system.

The point at which integration of control and data planes makes sense
will differ depending on line speed and current software technology.
C-Port's Lidington described the result as a "zipper effect," with the
melded point moving up and down as requirements change.

To counter that effect, the industry should be developing APIs that
provide consistent software across all areas of networking: core, edge
and access. "That's where we want to be over the course of the next
calendar year," Lidington said.

A similar effect may hold for hardware, as companies experiment with
putting the control-plane processor, typically an off-the-shelf MPU,
and the data-plane processor — generally a specialized network
processor — on one die.



Intel in particular is merging the two, combining data-plane RISC cores
and a StrongARM processor for the control plane in its IXP1200 packet
processor. That move might be wrong for the OC-192 market but
works just fine for the lower-end T1, T3 and OC-12 pipes, which is
where the bulk of the revenue is, said Doug Carrigan of Intel's network
processor marketing group.

Cost pressures in those markets make the integration of the
StrongARM — "getting a microprocessor out of the way" — sensible,
Carrigan said. Intel officials made it clear that they aren't yet
targeting the high-end, OC-192 or OC-768 levels of processing.

For its part, EZchip is able to handle OC-192 processing primarily
because it doesn't use RISC, according to company president
Fruchter. "The [processors] that are based on RISC machines, I do
not think they can scale to 10 Gbits/s," he said.

Computational bear
Companies choosing to concentrate on classification drew some
attention last week. Classification, which involves comparing a
packet's contents to a table of rules for routing or security, turns out
to be the most computationally difficult step in packet processing.

"It's almost a one-sided argument: The classifier function is the most
computationally intensive," said Graham Allan, product line manager
for SiberCore Technologies (Kanata, Ontario).

As specialized chips emerge for classification, they are being lumped
under the name "coprocessor." Usually these are large
content-addressable memories developed by the likes of SiberCore,
Netlogic Microsystems and Lara Networks; or specialized hardware
such as the chips being designed by Solidum Systems, Switch-On
Networks or Fast-Chip.

"A lot of the processors are starting to acknowledge they need a
coprocessor," said Andrew Sorowka, vice president of marketing for
SiberCore.

In the case of CAMs, the fact that every vendor has a proprietary
interface means that designers of packet-forwarding chips are making
sure their processors support multiple CAMs, Allan said. It may be
awkward, but the industry couldn't agree on a standard interface due
to the variety of existing OEM equipment.

"It's kind of a chicken-and-egg problem where all the eggs have been
laid," he said.

Still other companies hope to handle classifying and packet processing
in a single chip. The one-chip solution saves space and cost, said
EZchip's Fruchter, and also avoids the interface issues of a CAM.
"Having coprocessors is an interim solution," Fruchter said. "Once [the
technology] is mature, they will want it on a single chip."

But CAM vendors say they have an advantage in speed. Other types
of classifier chips "are still ASIC-based — they require algorithms to do
their searching" and are therefore slower, said Allan of SiberCore.

Looking ahead, Intel general manager Charles Giorgetti said that
manufacturing processes alone will not keep up with the growing
demand for bandwidth. Without specifying details, Giorgetti noted in
his keynote speech that architectural advances would be required to
keep pace with cutting-edge bandwidth needs.

Intel has several teams working on separate types of advances,
exploring "radical" ideas in areas such as pin interfaces and memory
interfaces, Intel's Carrigan said. Details of these efforts probably
won't emerge until early in 2001, he said.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext