Taking a break from our ongoing evaluations of various hardware platforms for ASIC design, this round of EDA platform benchmarks looks at platforms for FPGA design. With device capacities expanding to the million-gate range (and beyond), we expected FPGA synthesis and layout tasks to challenge desktop platforms. We were wrong! Our benchmark results show that you can comfortably run huge FPGA designs through a Windows NT PC whose processor and memory are relatively modest by today's ASIC design standards.

The benchmark circuits include a picoJava processor from Sun Microsystems that we managed to fit into a Xilinx Virtex 1000 FPGA using Synplicity's Synplify for synthesis and the Xilinx Alliance place-and-route tool. We also benchmark two variants of the Talisman hod design that we've long used for ASIC design tests. If you normally work with ASICs, you'll be impressed by the short turnaround times on the FPGA benchmarks.

As usual, we encountered many fascinating aggravations in the course of running those benchmarks. Our efforts to stress both hardware and software routinely pay off in failures that illuminate the limits of the design process. By the same token, we sometimes discover unexpected prizes. In the latter category for this round of benchmarks is the Sun Community Source Licensing (SCSL) program a major boon to EDA testing.

The source for Verilog source code

One of the challenges of benchmarking EDA platforms is the need to find appropriate designs. The designs must be freely available so that others can duplicate our tests. That means that we either have to own the designs and make them available or obtain them from public-domain sources that are open to all and sundry.

The designs must also be of the right size and complexity to stress the platforms that we're benchmarking. Even in the short time since we began this benchmarking series (about two years ago), we've seen such strides in processor speed and memory capacity that once-challenging designs have become painless for the latest desktop systems. We have thus resorted to multiplying relatively small designs by as many as 256 instances to generate just the right level of complexity. Such benchmark circuits aren't entirely satisfying, though, because "real" designs lack that regularity of structure.

What a joy, then, to delve into the world of the SCSL. Available via the Sun Web site (www.sun.com), SCSL offers the same source code that Sun designers used to build the company's hardware and software products. By agreeing to the licensing terms, you can download a wide range of tasty goodies, ranging from the source code for Sparc processors and the Jini connection technology to HPC Cluster Tools (such as Sun's Message Passing Interface Library and Parallel File System) and the Java platform.

Figure 1 - picoJava core benchmark

Sun's picoJava core provides an excellent challenge for benchmarking the high-end FPGA design flow. This diagram shows the core's major blocks as well as the changes we made. We also deleted the unconnected scan I/Os.

The licensing terms vary from one piece of IP to another, but in all cases SCSL gives you free use of the code during initial evaluation and development phases. Since EDA testing doesn't go beyond the evaluation phase, we have a no-fee source for practical designs.

Called before the bench

Sun's picoJava core constitutes a small microprocessor that directly executes Java bytecode instructions natively as defined by the Java Virtual Machine. That job description might seem to fly in the face of Java's "write once, run anywhere" philosophy, but the idea is to maximize the efficiency of executing a Java program thus minimizing overhead while preserving the benefits of platform and location independence. In other words, you can execute Java code on a variety of platforms, and you can do it with a high level of efficiency on a picoJava platform. PicoJava's native bytecode execution makes this efficiency possible; other processors have to interpret or dynamically compile bytecode using a just-in-time compiler.

We chose the picoJava-II version for our EDA platform testing. The picoJava-II download from Sun includes the picoJava-II Programmer's Reference Manual, the software development environment, the simulation environment, RTL design files, a verification test suite, sample scripts, and RTL documentation a rather sizable 177 Mbytes of source code and documentation. Part of that documentation consists of various handy HTML files that allow you to explore the design's Verilog hierarchy using a Web browser.

The picoJava core is certainly a sophisticated little processor. It has a six-stage RISC pipeline with forward instruction folding so that it can execute legacy C/C++ code "at a compatible price/performance with any other single scalar high-performance RISC processor operating at the same clock frequency," according to Sun literature. The core also provides thread synchronization and a variety of garbage collection methods, as well as method invocations and the hiding of loads from local variables, thus streamlining object-oriented programming. The most commonly used instructions are executed in hardware, while complex instructions are microcoded and the most complex ones trapped and emulated in software.

As it comes from Sun, the picoJava core is a little too big to fit in even the largest FPGA. We therefore deleted the floating point unit and scaled the core's instruction and data caches to 8 kbytes each, which represents the midpoint of their specified 0-to-16-kbyte ranges. We also commented-out the unconnected I/Os to modules for scan in/out/enable. Every picoJava module has a scan-out pin that is unconnected and undriven. In an ASIC these I/Os would be connected, but an FPGA doesn't need them because it allows other methods to test for stuck-at faults. We found that Synplify complained about the unconnected I/Os, so deleting them can simplify your life.

Note that Sun designates the FPU and the caches as configurable blocks, and they were indeed easy to configure. The picoJava block diagram in Figure 1 indicates the blocks we modified. Our final picoJava benchmark contains 649,770 gates and claims an 81 percent utilization of our target FPGA.

Although we normally post our benchmark source code on the ISD Web site, we haven't posted the picoJava code. One of the conditions of the SCSL research license is that you can't distribute the technology without Sun's permission, and there is little reason to trouble the lawyers in this case. If you want to duplicate our benchmark tests, you can download the picoJava package directly from Sun at www.sun.com/microelectronics/communitysource/picojava/techinfo.html. Just remember to delete the scan chain and FPU and scale the caches. We "blackboxed" the instantiated RAM from Synplify (using the Synopsys translate_off and translate_on pseudo-comments) and let Alliance implement the RAMs using the Virtex RAM blocks. Whether your version of picoJava is identical to ours is less important than obtaining a comparable design for testing the design flow for large FPGAs.

Note that we didn't run Sun's test vectors against our modified picoJava code, nor did we verify the design in any other way. Because the nature of the EDA benchmarks makes design quality issues unimportant, we don't verify our benchmark designs unless the verification tool is intrinsic to the tests (such as in our Verilog-XL benchmarks).

We take great care to duplicate a realistic design flow in all other respects, however, and we were delighted to see that a core as complex as picoJava shows every promise of working in a single-FPGA implementation. We hope to take the design to completion in the future. In the meantime, if you duplicate our benchmark tests and/or generate an FPGA-based picoJava, please let us know.

The Talisman benchmark lives on

Figure 2 - Virtex FPGA architecture

Our target FPGA, Xilinx's million-gate Virtex device, includes RAM blocks as well as a huge collection of configurable target blocks. Four digital phase locked loops (DLLs) help minimize clock skew.

Past benchmarks have proven again and again that the performance of EDA tools and hardware platforms can vary greatly from one design to another. Thus, even though picoJava seems the ideal benchmark to challenge today's FPGA flow, we also include a design from our ASIC-benchmark arsenal: Talisman hod. Talisman is a graphics engine jointly designed by Microsoft and Cirrus Logic. Microsoft gave us free use of large portions of the source code (most notably a section called hod) for our benchmarking project.

Our existing Talisman hod circuit was too large to fit in an FPGA, so we slashed away at it until we came up with a 946,400-gate version. Then we slashed further to get a 396,800-gate version. You can obtain the Verilog code for both of these benchmark circuits at www.isdmag.com/edabenchmark.

The 946,400-gate version of Talisman hod demands nearly 100 percent utilization of our target FPGA, so we dubbed it Talisman_100. We knew that the probability of this design actually fitting into the FPGA wasn't zero because we learned in physics that nothing has a probability that is identically zero, but we figured that we would be sniffing at zero's door with this effort. We just wanted a benchmark that would provide something of a challenge to a desktop PC. In contrast, the 396,800-gate version requires only 60 percent utilization (hence, Talisman_60), so it represents a more realistic design.

The million-gate FPGA

Figure 3 - FPGA configurable logic block

The CLBs in our target FPGA include a diverse set of resources ranging from a lookup table to a multiplexer. Each CLB contains four of these sets of resources.

Our target FPGA is a member of the Xilinx Virtex family, the XCV1000. This monster has 1,124,022 system gates (27,648 logic cells), 512 user I/O pins, and four digital delay locked loops to provide clean clock distribution. Xilinx claims clock-to-output delays of less than 3 ns.

An overview of the Virtex architecture appears in Figure 2. The FPGA's configurable logic blocks (CLBs) are in the center of the chip, surrounded by RAM blocks, I/O interconnect areas (VersaRing), configuration logic, and I/O blocks. Figure 3 shows a quarter of the resources in a Virtex CLB. Thus, the lookup table, multiplexer, flip-flop, and other elements are replicated four times in each CLB. For routing purposes, each CLB has two slices; each slice contains two sets of the resources shown in Figure 3.

Taking advantage of these coarse-grained FPGA resources to implement a general-purpose circuit requires specialized synthesis and layout support. As mentioned earlier, we used Synplicity's Synplify for synthesis, followed by Xilinx's Alliance place-and-route tool. The distinct functions in Alliance include translation, mapping, timing analysis, place and route, and a final timing analysis.

View from the GUI

If you are used to ASIC design, you'll find FPGA tools a little different. Specifically, the FPGA tools place greater emphasis on the use of graphical user interfaces (GUIs). As a result, both Synplify and Alliance are easy to use easier than most ASIC tools but batch-mode operation isn't always seamless.

Scripts are critical to the benchmarking process because they enable us to repeat complex tool functions in a consistent way.

For example, Synplify balked at using design files from our network server when we first experimented with the tool in batch mode. Synplify had no problem retrieving the files when we ran it interactively via its GUI, and using design files from a local disk was never a problem. Since we always run benchmarks from each machine's local disk to avoid variations due to network traffic, the block on network access wasn't a problem. We also noticed that when we aborted Synplify from the keyboard, NT's task monitor process list showed the task continuing for another couple of minutes, clearly reluctant to surrender. When Synplify finishes a run normally, however, it doesn't loiter around. We had no problems logging accurate run times.

Automating Alliance was a little more of a problem because we couldn't control all of its functions with batch commands. We were able to write a macro to perform those functions, though, and then we initiated the macro with a script. We weren't able to include Alliance's Timing Analyzer function (invoked with "timingan") in our benchmarks because when told to exit, the tool pops up a dialog box asking if you're sure you want to exit. The batch file doesn't know how to click on "yes."

Scripts are critical to the benchmarking process because they enable us to repeat complex tool functions in a consistent way. Our carefully nested sets of scripts also provide the basis for consistently measuring tool execution times. If a tool doesn't exit cleanly, we can't time it accurately, so we simply left the timing analyzer out of the benchmark.

If you're not in the benchmarking business, greater reliance on GUIs makes sense so long as the design process is short and involves few iterations. Why develop a script that you're going to use only a few times? Just set up the FPGA tools the way you want, run them a few times, and you're done.

FPGAs have traditionally been small enough to allow this fast design flow. Even as FPGA capacities have increased, improvements in design tools have kept turnaround times manageable. But will the multimillion-gate FPGAs now entering the market change that picture? And what about the growing use of compute farms, which rely on batch-mode processing?

We asked Jeff Garrison, Synplicity's director of marketing for FPGA products, about the company's view of batch-mode versus GUI operation. Noting that Synplicity supports both TCL and batch mode along with the GUIs, he observed that the issue is "really a matter of personal preference, although scripts allow you to be efficient with licenses and also get consistency. We focus on being easy to use, easy to control, so there aren't too many button clicks. Our philosophy is to allow you to control the design, not so much the tool." Indeed, Synplify has few constraints to set.

All that being said, Garrison does see a shift underway. "With the introduction of the bigger FPGAs," he says, "we are starting to see more use of batch mode at bigger companies. As more ASIC designers move to FPGA design, we expect to see more batch mode use."

A rev a minute

In addition to the batch-versus-GUI differences between ASIC and FPGA tools, we also noticed that the latter tools seem to go through upgrades much more often. Both the Synplicity and Xilinx tools went through revisions while we were working on them, and we could see that their rev histories were almost frantic compared with those of many long-standing ASIC tools. We considered that the ASIC tools had been around longer and are therefore more mature, but we couldn't fully account for the difference.

Synplicity's Garrison explains that in contrast to fine-grained ASIC structures, FPGAs have coarse structures that vary widely from one vendor to another. For best results, synthesis has to be customized for each FPGA architecture. "People don't realize that FPGA synthesis is actually harder than ASIC synthesis," he says.

Keeping up with the large number of vendors in today's FPGA market only makes the task more difficult, especially considering the importance of immediate support for the latest devices. As a result, says Garrison, Synplicity generally releases a new rev of the software about once a quarter.

Our benchmark efforts benefited from this enthusiastic schedule because the first version of Synplify (5.1.5a) couldn't handle the entire picoJava design. We separated picoJava's integer unit from the rest of the design and pressed forward, but the result crashed the Alliance software (version 2.1i). At about that time, we received new versions of both Synplify (5.2.2a) and Xilinx (service packs 21i_sp1_alliance_pc.exe and 21i_sp1_data_pc.exe). These revs fixed the problems, and the new version of Synplify executed about twice as fast as the previous one.

Desktop foundries

For the FPGA design tasks, we benchmarked these systems:

• 550-MHz Compaq SP700 with a single Pentium III Xeon and 1 GByte of DRAM
• 550-MHz IBM Intellistation Z Pro with dual-Pentium III Xeon processors and 2 GBytes of DRAM
• 400-MHz dual Pentium III Xeon PC with 512 GBytes of DRAM
• 300-MHz Pentium II PC with 512 GBytes of DRAM

All of these systems are running Windows NT 4 with Service Pack 3 and have a 100-MHz front-side bus (except for the 300-MHz machine, which has a 66-MHz bus). The latter PC was among the first systems we benchmarked when we began these tests more than two years ago, and it continues to serve as a benchmark to the benchmarks. Similarly, the 400-MHz PC represents another typical level of benchmark performance. To avoid confusion with newer models we don't specify the manufacturers of these machines, but we want to acknowledge the generosity of Compaq and IBM in allowing us to continue using these products in our tests.

Figure 4 - Do you know where your DMA is?

Although WindowsNT doesn't tell you clearly whether your system is taking advantage of your disk drive's Ultra DMA mode (unless you're using some after-market drivers), you can find out with a utility called DMACheck.

Because the FPGA benchmark designs are smaller than most of the designs we have been using for ASIC benchmarks, we expected our fleet of PCs to run the EDA tasks handily. In fact, since we had pegged the average ASIC design system at 256 MBytes of DRAM, we wondered whether a 128-MByte system would do the trick for FPGA design.

We were impressed by how quickly the PCs dispatched the synthesis and layout tasks faster than we expected. But 128 MBytes of DRAM isn't enough to handle a million-gate FPGA design. We tested only one machine that had a memory that small: a 400-MHz mail-order PC that we inherited in a corporate merger. This system synthesized the smaller Talisman hod benchmark in about 23 minutes, compared to about 14 minutes for the other 400-MHz PC with 512 MBytes of DRAM. But when the 128-MByte machine continued to run place and route past the 63-hour mark, we decided to put an end to an unfair test. The 512-MByte machine had already dispatched place and route in about 4 hours.

The extreme divergence between 4 and 63+ hours can be explained only by saying that paging to disk is a huge burden. We can also speculate that the mail-order system's disk I/O is less than first rate and unaided by Ultra DMA. As we noted in our last benchmark installment ("EDA Platform Benchmark: When Should You Upgrade EDA Hardware?" October 1999, p. 53), UDMA can double disk I/O performance but is often disabled in Windows NT/95/98 systems. (In fact, the lack of UDMA would account for the slow time of the 128-MByte machine on the synthesis run.)

Figure 5 - Synthesis performance

This portrait of performance on two synthesis benchmarks could hardly be simpler. The two 550-MHz PCs turned in performance that never differed by as much as a percentage point. Our 400- and 300-MHz baseline PCs ran about as fast as you would expect them to.

Unfortunately, Windows NT doesn't clearly tell you whether UDMA is enabled. The easy method for checking that we described in our previous benchmark report works only if you are using some after-market UDMA drivers. Otherwise, you need to run the DMACheck utility that comes with NT 4.0 Service Pack 3 in support\utils\i386\. You can also download the utility from the Microsoft Software Library. The utility clearly shows the status of your drive's interface (see Figure 4).

File-system follies

Along with the UDMA question, the 128-MB PC brought up another disk-related issue: are you better off using FAT or NTFS as the file system on your NT disk? In our very first benchmark report ("EDA Platform Benchmark: Simulation," March 1998, p. 62), we showed that FAT (the original Windows file system) runs a little faster than NTFS (the Windows NT file system).

In a roundabout way, we learned about the downside of NTFS in the course of the latest benchmark tests. We lacked the passwords for the mail-order PC that we inherited, and according to Microsoft you can't get into an NT system without passwords. A few minutes of Web searching turned up a quick solution: boot from a floppy, delete a couple of NT files, and you have a new system. That procedure successfully deleted the system's existing accounts.

As a result, FAT poses a security problem. NTFS, in contrast, requires a special program that enables the user to mount and modify the NTFS disk without the passwords a somewhat more difficult break-in scenario.

Figure 6 - Synthesis run times

It takes surprisingly little time for Synplify to synthesize a million gates, so long as you have enough DRAM. All of these systems contain at least 512MB.

The more obvious downside to FAT is its inefficient 16-bit file space. We found out about this limitation, too, on a PC that had a 2.5-GByte FAT drive. Even though the drive on this system contained only 600 MB of actual files, the system issued "disk full" warnings. Lots of tiny files were taking up big minimum file spaces, wasting most of the disk capacity. We needed NTFS's 32-bit file space, and converting to NTFS using an NT utility reclaimed almost 2 GB of space.

We then set out to convert several other systems. The first of these converted with no problems. On the second system, things broke. When logging in, for example, normal users saw error messages about being unable to connect to ADMIN$ or C$ administrative shares. Further, only administrative users were able to access Microsoft Word. We created new shortcuts to the Word executable, and the normal users who had formerly been authorized to use Word could once again gain entry. Despite the hazard, we converted a few more systems to NTFS. They converted more or less without problems, although we were careful to check results and fix little problems immediately after conversion.

Hourly synthesis runs

Aside from the revelation that PCs with a moderate amount of DRAM (by ASIC design standards) handle FPGA design tasks quite well, the results are extraordinarily predictable. In fact, this marks the first time we have ever failed to see odd variations among the systems and benchmarks.

On the synthesis runs, the performance of the two 550-MHz PCs is essentially identical (see Figure 5). As usual for our benchmark tests, we repeat each run three times on each platform, then average the results. The actual run times for the IBM and Compaq 550-MHz machines differ by only tenths of a second, which is well within the measurement accuracy of the tests. Again, we have never before seen such consistently identical results.

The 400- and 300-MHz baseline PCs turned in respectable performances that are pretty close to the levels predicted by their processor speeds. The 400-MHz system represents a 27-percent reduction from 550 MHz, and the benchmark performance level is 26 to 23 percent lower. Similarly, 300 MHz is about 45 percent slower than 550 MHz, and the benchmarks come in at 41 to 37 percent lower.

Figure 6 shows the actual synthesis run times. Note that even the largest design on the slowest machine (picoJava on the 300-MHz PC) runs through Synplify in only 81 minutes. Take a long lunch, synthesize a million gates! You can cut that time to 47 minutes on the fastest machines, but either way you'll fit a lot of FPGA synthesis into your day.

Note that the Talisman synthesis results in the charts are for Talisman_100. We didn't chart the synthesis results for Talisman_60 because the execution times were too short to meet our minimum time limit of 20 minutes. We want to avoid introducing new benchmarks that take less time than this to run, because a year from now new systems will be running them in 5 minutes, and timing accuracy will become a problem. Already, on our fastest platforms, the Talisman_60 Synplify run takes only 11 minutes.

Place and route like clockwork

In keeping with the predictability theme in this set of benchmark results, the execution times for the Alliance place-and-route tool were virtually identical from one run to another on the same machine. This regularity contrasts with the results we saw on our previous Snaketech place-and-route benchmarks ("EDA Platform Benchmark: Place and Route," July 1999, p. 68), where variations of several minutes were common. Xilinx's Alliance obviously uses a more deterministic approach to layout.

To no one's surprise, the 100-percent FPGA utilization required for the Talisman_100 benchmark made this design impossible to route. We therefore ran only the translation, mapping, and placement functions in the Alliance software. The Talisman_60 went through all the place-and-route functions.

The picoJava design also went through place and route, but for some reason Alliance couldn't handle flip-flop-to-flip-flop (clock) constraints for this circuit. (Xilinx has duplicated this problem and informs us that they will fix it in either the next Alliance release or service pack.) We tried three different ways of specifying the clock:

• NET "clk" TNM_NET = "clk";
  TIMESPEC "TS_clk" = PERIOD "clk" 20 ns
  HIGH 50%.
• TIMEGRP "FFS" = FFS ("*");
  TS_P2P = MAXDELAY FROM "FFS" TO
  TIMEGRP "FFS" 20 ns;
• TIMESPEC TS02 = FROM FFS TO FFS 20;

Each of those efforts generated the out-of-memory error. We also tried slowing the clock to 5 kHz and still ran out of memory, so the problem isn't related to speed. We also experimented with the following set of constraints:

• TIMESPEC TS03 = FROM PADS TO PADS 40;
• TIMESPEC TS04 = FROM FFS to PADS 40;
• TIMESPEC TS05 = FROM PADS TO FFS 40;

These constraints didn't produce "out of memory" errors, but in the end we ran the actual picoJava benchmark tests with no constraints at all. Specifically, we used the PAR command for place and route with the ýX option to denote that there was no constraint file. The flip-flop-to-flip-flop constraint worked fine for Talisman_60, so that benchmark includes full timing-driven placement and routing. Constraints weren't an issue for Talisman_100 because it wouldn't route anyway.

Figure 7 - Place-and-route performance

The two 550-MHz PCs showed tiny performance differences on the place-and-route benchmarks, but they swap places on the two Talisman runs. The conclusion: both machines handle the tasks spectacularly well.

Despite these differences among the benchmarks, the results were routine (see Figure 7). As with the synthesis benchmarks, the place-and-route run times show the two 550-MHz PCs in a dead heat. These machines are always within 3 percent of each other and swap rankings on the two Talisman benchmarks. The 400-MHz system once again comes in 26 to 23 percent below the 550-MHz systems. The 300-MHz PC shows a little more variability on place and route, but is still 40 to 48 percent below the fastest machines.

The actual run times for place and route appear in Figure 8, but bear in mind that each benchmark involves a different type of task. Although Talisman_60 is the smallest of the circuits, it takes the longest because it's the only circuit on which we could run full constraint-driven place and route. Talisman_100 takes a surprisingly long time to just get through placement, and picoJava takes a surprisingly short time to go through both placement and non-clock-constrained routing.

Even the longest task (placement and routing) on the slowest machine (Talisman_60 on the 300-MHz PC) takes less than 6 hours. You could use this machine to turn around synthesis, placement and routing, and programming the FPGA in a single work day. With one of the 550-MHz systems, you could conceivably do the entire job before lunch.

Figure 8 - Place-and-route run times

The run times for the three benchmarks can be deceptive unless you know what actually ran. Talisman_60 took the longest to run because it was the only circuit to go successfully through the complete timing-driven place-and-route sequence. The Talisman_100 underwent only the placement stage. The picoJava benchmacrk went all the way through place and route, but without timing constraints.

Grab for the gusto

So what kind of machine do you need for FPGA design? The cost of fast Pentium III systems these days makes speed a non-issue. Buy the fastest one you can get (why not finish before lunch?) but think hard about how much memory you put in it. For a while, memory prices were so low that the easy answer was to install as much memory as you could fit in the box. But memory prices have fluctuated wildly of late, making us wonder when DRAM futures will begin trading like hog bellies and whether the max-out-the-memory approach will continue to be affordable.

Certainly, 128 MBytes isn't enough, as shown by the following tabulation of memory usage:

Synplicity Synplify

• picoJava - 350 MBytes
• Talisman_100 - 150 MBytes

Xilinx Alliance

• picoJava - 230 MBytes
• Talisman_100 - 530 MBytes
• Talisman_60 - 360 MBytes

If you want to handle designs about the size of picoJava, a 256-MByte system would put you right on the edge of efficiency. We would recommend 512 MBytes with an option to purchase 512 MBytes more for delivery this time next year. Xilinx has already upped the maximum Virtex capacity to two million gates, with more on the way. You can handle designs for these high-capacity FPGAs easily on your desktop, so long as you have enough DRAM.

The authors would like to thank Mark Fearon, principle design engineer at Intrinsix, and Ilya Shenfinkel, senior design engineer at Intrinsix, for their assistance in preparing and running this set of benchmarks.

James Lee is a principal consulting engineer at Intrinsix. He has 12 years' experience working with Verilog and was one of the first employees at Gateway Design Automation, which developed Verilog. Prior to joining Seva (now Intrinsix), he was with Cadence Design Systems. James is also a part-time instructor in Verilog at the University of California, Santa Cruz. The second edition of his book Verilog Quickstart has recently been published.

Bob Peterson is a free-lance writer in Monterey, California. Formerly assistant managing editor of EDN magazine, he has written on a wide variety of technical topics for many publications and companies for the past 17 years.