ChipCenter Questlink
SEARCH CHIPCENTER
Search Type:
Search for:




Knowledge Centers
Product Reviews
Data Sheets
Guides & Experts
News
International
Ask Us
Circuit Cellar Online
App Notes
NetSeminars
Careers
Resources
FAQ
EE Times Network
Electronics Group Sites

RAS SERVER IMPLEMENTATION


Circuit Cellar Online
THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

DESIGNING A DSP-BASED RAS SERVER

Lessons from the Trenches Part 2: Implementation
by Shawn Arnold

Start ý Network I/F ý Telco I/F ý Sources and PDF

NETWORK I/F

The Network I/F involves the connections of a DSP to the host controller via the DSP's parallel port. It also involves the connections of control signals between the DSP and host. These connections give rise to several important design considerations and issues. Three issues I will cover are the number of ports, parallel port connections, and control signaling.

In most all RAS server designs, the host is responsible for supporting the network data flow to a large bank, or pool, of DSP ports. The total number of ports is limited by two important criteriaýhost controller MIPS and physical bus restrictions.

Want MORE...unique applications, complete projects, practical tutorials, and useful design techniques?

Subscribe to Circuit Cellar magazine

Written by Engineers
for Engineers.

 

Depending on the chosen host controller, the general rule of thumb for processing MIPS per port is anywhere from 1.0 to 2.5 MIPS. So, depending on what tasks the host must perform, the MIPS per port must be factored into the equation, which determines the MIPS requirement from the host controller, and ultimately affects on what host controller is chosen to implement the host in the RAS server design.

Issues that might restrict the number of ports a host can physically connect to are static loading, dynamic loading, and power dissipation. Although an in-depth discussion of each of these areas is beyond the scope of our present discussion, I will briefly introduce the important points of each issue.

Static loading refers to the equivalent resistive loading of a node on the parallel bus that connects the DSP and host. Basically, it's the criteria that any output driver on a node must be able to statically drive the sum of all DC input currents on the node. This becomes an issue when the number of inputs on the node is large. However, because most digital logic circuits are designed with today's advanced CMOS logic technologies, which provide low DC input currents, static loading is usually not an issue with most host-to-DSP parallel connections. The other issues usually become a problem well before static loading does.

Dynamic loading refers to the bandwidth of the parallel bus that connects the DSP and host. With several dozen ports connected in parallel, the sum of parasitic capacitance tends to slow the parallel bus down, lowering its bandwidth. An analysis of the required bandwidth of the bus, which depends on the estimated peak data flow on the bus and the actual bus bandwidth, must be performed before a design is finalized.

The required bandwidth must take into account all the activity and data flow that could take place on the parallel bus. This includes the actual network data flow, firmware loads (if they take place over this bus), and any other control or status information flow on the bus. The actual bandwidth estimate must take into account output driver bandwidths or output driver output resistance and estimate parasitic capacitance of traces and device input pins.

As far as these physical issues are concerned, dynamic loading is usually the dominate issue in determining the number of ports a host controller can support. However, there are several ways to combat this issue. For example, buffering can be used between the host and smaller groups of ports. Or, on the software side, the data transfers can be designed for maximum data density, where each transfer should pass data over the full width of the bus.

Power dissipation involves the charging and discharging of the large parasitic capacitance on each node on the parallel bus that connects the DSP and host. Each cycle of a data transfer involves the charging and discharging of the nodes on the parallel bus. The larger the parasitic capacitance and the faster the transfers, the more charge needed to be dissipated in a shorter amount of time. This current energy has to be dissipated somewhere. It dissipates in the output drivers of the host, which source and sink the currents on the bus nodes.

If the capacitance of the node becomes so great or the frequency of the transfers becomes so large that power dissipation could become an issue, then it is likely that dynamic loading will become the first issue. In most cases, dynamic loading becomes an issue before power dissipation does.

There are two straightforward issues involved with the parallel port connectionsýparallel port bus (separate versus multiplexed address and data buses) and parallel port selection (see Figure 1).

Figure 1ýOne possible parallel port design shows a separate address and data bus design, requiring less glue logic, but increasing the DSPýs pin count and thus package size. Another possible design shows a multiplexed address and data bus design, requiring some glue logic but reducing the DSPýs pin count and package size.

 

There are two disadvantages to separate address and data parallel bus signals. Both compromise the most important DSP design specification—size. First, extra PCB space is required for routing the additional traces. Second, and more significant, separate address and data bus signals mean a higher DSP pin count, which means a larger DSP package size.

Because separate parallel port address and data buses mean a higher pin count for a DSP package, and thus a larger package size, most DSP parallel ports have a multiplexed address and data bus parallel port.

The disadvantage of multiplexed bus signals is a more complex logic interface between the host controller and the DSP port. Decoding logic must be provided to distinguish between an addressing cycle and a data transfer cycle. Because this logic interface is often implemented via PLDs, the increased complexity is usually not a significant issue.

Because the host controller is connected to several dozen or more DSP parallel ports, the selection of a specific parallel port for a data transfer becomes a design issue. There are two approaches to the design of the selection logic, address decoding and select register.

Address decoding is easily implemented by memory mapping each DSP parallel port into the host controller's memory space. Any transfer to a specific DSP parallel port is done so by addressing the specific parallel port in host controller memory (see Figure 2).

Figure 2ýThe address decoding approach to selecting a DSPýs parallel port for data transfer. Each DSP is simply assigned a specific memory location in the hostýs memory space (i.e., the DSPýs are memory mapped into the hostýs external memory space).

 

A selection register is implemented by memory mapping a register into the host controller's memory space, where each bit in the register is the input select signal for a specific DSP's parallel port (see Figure 3).

Figure 3ýThe select register approach to selecting a DSPýs parallel port for data transfer. A select register is implemented, such that each register output signal selects a specific DSP. The host writes the register with the desired value that selects the desired DSP.

 

Address decoding is the easiest and most clear-cut approach to selecting a DSP parallel port. For this reason, it is the preferred method. However, certain circumstances may require the implementation of a selection register. For example, if the host controller address pins were, for some reason, limited.

Control signaling refers to the DSP control signal connections, which are not associated with a parallel port connection. These signals can be any combination of the following:

ý reset input to the DSP
ý interrupt input to the DSP
ý flag output from the DSP

Depending on the level of flexibility desired, any combination of these signals can be used. Note that none of these signals are required to be connected between the host controller and DSP port. However, if one or more of these signals is desired, the issue then becomes how the host controller will select a DSP input signal for driving or a DSP output signal for sensing.

There are three approaches to the design of the selection logic, two of which are the same as DSP parallel port selection, address decoding, signal registers, and DSP control registers.

Address decoding is implemented by memory mapping each DSP signal into the host controller's memory space. Any manipulation of a specific DSP input control signal is done by addressing the specific DSP's signal in the host controller's memory space.

A signal register is implemented by memory mapping a register into the host controller's memory space, where each bit in the register is the input control signal for a specific DSP. The selection registers are indexed or addressed by a control signal type.

And, a DSP control register is implemented by memory mapping a register into the host controller's memory space for which each bit in the register is one of the input control signals for that DSP. The control registers are indexed/addressed by DSP port number. Again, address decoding is the easiest and most clear-cut approach.

Note that selection and control register methods are essentially the same design. The indexing is simply reversed. Also, note that in the control register case, a bit for parallel port selection can be added to each DSP's control register.

Sensing can be done via a memory-mapped register in host memory space, where each bit is the output signal from a DSP. However, because a flag output from the DSP to the host would be designed for interrupt purposes, the register inputs should be ORed to a single signal, which can be tied to a host interrupt input pin.

PREVIOUSNEXT


Circuit Cellar provides up-to-date information for engineers. Visit www.circuitcellar.com for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com or subscribe online. ýCircuit Cellar, the Magazine for Computer Applications. Posted with permission.
Click here to get your listing up.

Copyright © 2003 ChipCenter-QuestLink
About ChipCenter-Questlink  Contact Us  Privacy Statement   Advertising Information  FAQ