Customer Testimonial - Apex  

---

"We are reloading the Xilinx FPGA continually and are heavily reliant on the performance of the SpartanXL device."  Mark Sasten, Chief design engineer, Apex

Apex

Located in Redmond, Washington, Apex Inc. is the foremost maker of console switches for client-server environments. The devices allow operators to manage large numbers of LAN, WAN, or Internet servers from one or a few consoles. Before their advent, each server needed its own console, but as the size of networks grew, that became increasingly costly. Microsoft, one of the first companies to encounter the problem, asked Apex to solve it for them, and the console switch was born (See Sidebar). 

Although console switching is a simple concept - using few consoles to manage many servers -- designing one is challenging because of variations in server hardware and software. According to Tom Buiocchi, Apex's vice president of marketing, "There are usually many different server types In a farm, each with a different BIOS and video subsystem, and perhaps running different operating systems. In addition, server populations are growing and changing constantly." Thus fast, easy configurability and re-configurability are necessities. 

For example, Apex's new EMERGE 2000 switch, announced August 1999, has to juggle multiple BIOSs, keyboard maps and pointing system parameters. It has to be compatible with hundreds of combinations of video hardware and software, display resolutions, color depth, and refresh rates. EMERGE also has to adapt to operating systems ranging from Windows NT to various Unix flavors. 

And finally, in cases like secure "lights out" server installations, or where the console is located remotely from its servers, there is the connection between the console and the farm to consider. At best it might be a broad band optical or T-1 link; at worst, it could be a dial-up modem connection. EMERGE is specifically designed for remote applications. EMERGE has to take all these parameters into account as it switches from one server to another. That makes real-time reconfiguration the problem to be solve, and Apex decided that Xilinx SpartanXL FPGAs were the answer. Chief design engineer, Mark Sasten, used two Spartan XCS30XL FPGAs for the design. 

Designed to be one of the most compact console switches available, EMERGE is built on a single PCI circuit board. One of its FPGAs serves as a 32 bit, 33 MHz PCI interface (based on the LogiCORE IP core) and a video signal processor. The other SpartanXL is used for digital signal processing (DSP). The first SpartanXL not only manages the PCI bus interface (its core using less than 50% of on-chip resources), but also interprets the incoming video signal. The latter is a demanding application since the chip must calculate video resolution, refresh rate, and color depth from the raw video signal itself, and do it fast. It deduces this information by detecting and evaluating synch, framing, and other signals embedded in the video stream from the server. 

It then generates video control signals and passes the now organized video information to the DSP in the other SpartanXL. It also passes similar data to the switch's server-management software for local, windowed display of the server's video output. In addition to these functions, the first SpartanXL includes counters, a clock reference used calculate frame rate, an internal oscillator, and watchdog timers for dealing with power down and "sleep" settings. Most of the SpartanXL's programming is read into the FPGA at boot up. 

Although it also includes the system SDRAM and video buffer controllers, as well as an interface to the local system's microprocessor, the second SpartanXL is a DSP primarily used to overcome the problems of remote access. "We not only have to cope with variations in the video signal, but we also have to make sure that information moves over the link between the server farm and the console as quickly as possible," says Sasten. "Bandwidth demanded by high refresh rates, especially when coupled with high resolutions, can kill you; communications optimization is critical to remote console performance." 

Therefore, depending on the server selected, the DSP is continually determining the algorithm and amount of compression appropriate to both the signal and the communications line. "We swap communications optimization algorithms almost every time we switch to another server," says Sasten. The needed data is stored on disk and read into the second SpartanXL in milliseconds. To simplify things, Apex uses several predetermined communication scenarios for high (e.g., 100 Base T or T-1), medium (ISDN or DSL), or low speed (modem) lines. But for each scenario, the DSP's signal processing - filtering, detection, compression type and level -- varies depending on the server, and that means that the DSP is being reconfigured almost continually. 

Says Sasten, "We are reloading the Xilinx FPGA continually." And as implemented, the whole complex process takes only a few milliseconds, little more than the time needed for a screen repaint. "We are heavily reliant on the performance of the SpartanXL device." 

For more information on Apex, visit their website at www.apex.com. 

Products
Application Notes
Press Releases
Hard Copy Literature Request