Programmable Logic

FPGA Flexibility Enables Concurrent Board Design and Layout

How 3Com reduces total development time.

by Sid Gilbrech

The inherent flexibility of FPGAs can shorten design development times. At 3Com (Santa Clara, CA), we begin printed circuit board CAD layout while the internal FPGA design is still being completed. This approach can be a very effective way to speed up the development cycle, but it can also be risky if you don't consider some important factors. These factors include the routability, pin-out maintainability and performance of the selected FPGA, and the ease-of-use of the associated development tools.

The major advantage of concurrent design is that it allows an iterative design approach. Since the board design is fixed, all changes are made in the FPGA through the development software, resulting in a software level of flexibility not found in most hardware design. Thus, a "what-if" design approach becomes practical.

Concurrent design leads to a fast "time-hardware," since the PCB doesn't wait for the FPGA design to be finalized. It also allows early hardware/software integration. Though the FPGA design may not be complete, having a hardware platform for code evaluation and debugging is beneficial to software developers. Furthermore, hardware changes are easily made in the FPGA, if necessary, to accommodate fixes or enhancements. Finally, feedback from software engineers, other hardware engineers, or early customers can be easily incorporated into the design.

Concurrent design results in shorter development cycles, which lead to a faster time-to-market. During the first phases of the concurrent design process, there are two nearly independent tracks. The first track begins with the PCB schematic design, and the second begins with the FPGA design. After the first step, the board-level schematic is sent for CAD layout, and then the PCB is fabricated. Meanwhile, the FPGA design continues to be developed, simulated, and iterated. Once the PCB is available and the FPGA design is simulating correctly, the two are integrated and tested as the first engineering prototype (known as "Rev A"). Typically, ten of these boards are fabbed and five are built.

Most logic changes are done during this initial board-level debugging. In most cases, this can be accomplished by simply changing the design in the FPGA. In addition, preliminary FCC emissions testing is also done during this step.

The total development time--defining the project, implementing the board-level design, implementing the FPGA design, and making all necessary changes to produce a working product for the beta testing cycle--took about six months.

Draft version of the design When the FPGA has been selected, the designer should define the pin-outs by implementing a draft version of the design, including all anticipated I/Os. This draft design can then be compiled by the FPGA software to get pin assignments. If the FPGA was chosen correctly and after the FPGA pin assignments have been defined, it can be treated as a "black box," like the other standard components.

All board component connections are then defined and sent to the CAD group for PCB layout. In this case, high performance wasn't necessary, but we used the QL12x16B because we needed the high degree of routability and pin-out maintainability to speed our development cycle. One of the most important differentiators of this FPGA is the large amount of routing and interconnect resources.

The small size of QuickLogic's (Santa Clara, CA) ViaLink antifuse technology allows them to "fully populate" all of the routing crosses with programmable elements. Most other FPGAs use a less-populated scheme that tends to limit routability.

Since the ViaLinks have very low impedance when programmed, system timing targets are easy to achieve and to maintain during design changes. Another nice feature of this FPGA is the high fan-in cell, which allows complex functions to be implemented in a single level of logic.

Design flow Next we'll walk through the steps in the design flow used to develop this board design. The design flow can be broken down into distinct phases. The first phase is to design the printed circuit board, define the necessary FPGA requirements, and begin working on the FPGA design.

The specific steps for the PCB design are as follows:

1. Define the board functionality.

2. Choose the standard board components.

3. Select the FPGAs using the parameters discussed earlier, then implement a draft version of the design, and compile it to get the pin-outs.

4. Create the board schematics and send them off with the component pin connectivity to begin board layout.

The second phase of the design flow is to fully develop the FPGA design while the PCB is being laid out and manufactured.

During this phase the following steps occur:

1. The first full version of the FPGA design is completed. This design is generally the "draft" version (used originally to get pin assignment information), modified to have full functionality.

2. The next step is to develop a full set of simulation vectors that represents the board and the FPGA functionality and timing.

3. Any problems uncovered during simulation are corrected, and then the design is recompiled and resimulated. This iterative loop continues until the simulation shows that all functionality and timing is correct.

The third phase of the design flow occurs once the manufactured printed circuit board becomes available. For the I431 design, this phase started about four months from the time the project was begun.

During this phase the following steps occur:

1. All of the components, including the programmed FPGA, are plugged into the board.

2. Software is integrated with hardware, and the board is powered-up and tested.

3. Changes are made to the FPGA design, as necessary, to correct any problems.

At this stage there may also be board-level problems that can't be corrected in the FPGA. If this is the case, then the board is sent back to the CAD group for the necessary layout changes and then re-manufactured.

Once the board has been completely debugged and is working correctly (for this design, about a month after the boards became available), 25 to 50 copies of a "beta" run are produced and sent into an extensive testing and Q/A cycle. This process includes (1) accelerated life testing with extreme temperature and voltage conditions, (2) a Q/A-Q/E cycle to ensure reliability, and (3) emissions testing to guarantee the board meets EMF requirements.

The cycle took about one month for this project. When the quality cycle is complete, the boards are available to be shipped to customers. If the boards require changes, the PCB group makes the required modifications. This is possible because during development, we were able to remove the FPGA from the socket. We could then replace it with a new FPGA programmed with the latest version of the design. When the production boards were completed, the socket was removed and the FPGAs were soldered directly to the PCB.

It might seem as though SRAM-based FPGAs or EEPROM-based CPLDs would be more suitable for concurrent board design--since you could reprogram the PLDs on the board without having to put them in a socket. However, we found that routability and pin-out maintainability were the most important PLD features for making concurrent design practical, and so the one-time programmable QuickLogic devices worked the best.

The next issue to address is how our methodology might change over the next few years. The most likely part of the design flow to change is the way we describe our FPGA designs.

Currently, we use schematic-based entry (though most of the engineering groups within 3Com have been using an HDL design flow based on Verilog entry and logic synthesis through Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys ). After the schematics have been produced, we run the FPGA place and route tools (which, in this case, are fully automatic). Then, we simulate the design, identify any problems, and go back to the schematics to correct them. We repeat the cycle until the design works correctly in simulation.

This approach has worked well for us in the past, but as design complexities continue to increase, we expect to change our methodology, as appropriate.

For FPGAs, there is a trend away from schematics toward hardware description languages (HDLs) such as Verilog and VHDL (other groups at 3Com have already made this transition). These languages allow complex designs to be described much more efficiently than with schematics. The languages should help us maintain the benefits of concurrent design as our FPGA density requirements increase.

The ability to quickly make changes, compile those changes, and see the results in simulation are the keys to fast design development.

As our group begins working with HDLs, we expect our software environment to change. We probably won't do away with schematics completely, because they tend to work well for performance-sensitive applications. However, we will begin to use HDLs, most likely Verilog. Using HDLs adds a logic synthesis step to the design process. The flow goes from design entry, through preliminary place and route, to simulation, to synthesis and technology mapping, and then back to design entry to make any necessary changes. With HDLs, though, even large changes can be made fairly easily.

The following are some of the specific benefits of Verilog versus schematics:

1. Verilog provides a high level of abstraction, which frees designers from the details of place and route. However, the FPGA must allow 100 percent automatic routability for the user to get the full benefits of the high-level design.

2. Since Verilog is a standard language, it allows designs to be easily ported from one piece of software to another. It also allows the same design to be tried in various FPGAs, even from different vendors.

3. It provides a means for designers to manage high-complexity designs, especially those over 5000 gates.

That concludes our look at our experiences with concurrent PCB/FPGA design and the directions we expect to take in the future.

Here is a summary of the main points:

1. Concurrent design is enabled by integrating the logic that is most likely to change into an FPGA, therefore confining all changes to the FPGA, when possible.

2. To facilitate concurrent design, the FPGAs selected must have a high degree of flexibility, especially for routability and pin-out maintainability.

3. Powerful software tools contribute to short, fast development cycles. The trend towards HDLs will improve the cycle times even more. *

Design example

We'll use one of my recent projects to step through the concurrent board design process. This particular project was an ISDN "superchannel" called the "I431." The objective was to effectively create one large-bandwidth ISDN superchannel from all 24 channels of a T1 line. The maximum system clock rate was only 16.5MHz, so FPGA performance was not a serious concern. However, the small board size did raise some concerns about the physical device sizes. Also, short development-time constraints required concurrent PCB development. Therefore, we needed an FPGA that was physically small but able to hold a fairly complex design. Also, it needed to be flexible enough to allow multiple design changes during the development cycle, without requiring the pin-outs to change. Figure 1. HSS - I431 Module block diagram The block diagram of the board-level design is shown above. On the left is the proprietary high-speed (800Mbit/s) bus into which the card is plugged. The CMPI is a core memory peripheral interface which connects the board to the bus. The EEPROM shown at the top is the board's P.I.D. ,which contains board configuration and I.D. information. On the right is the XPC--an intelligent serial controller used to move and serialize/deserialize data. We chose the XPC because 3Com had already developed a generic software driver. On the bottom right is a serial port used for diagnostics and user set-up. It interfaces with an 87C52 microcontroller--used for program control of the ACFA and PRACT framer and line-interface devices. The 87C52 also interfaces with the telecom control FPGA for setting the slot timing registers. The ACFA is a frame aligner for various ISDN primary rate formats. The PRACT is a primary rate access clock generator. Figure 2. Telecom Control FPGA block diagram The diagram above shows the internal workings of the telecom control FPGA. This part contains all of the glue logic necessary to interface between the 87C52 telecom controller and the PRACT, ACFA, and CMPI devices. It also supplies the slot time transmit and receive clocks to the XPC. The address latch (shown in the upper left) is used to demultiplex the 87C52 address/data lines. The 87C52, after reset on power-up or hot-swap, reads the hardware configuration switches on the board, and then it configures the ACFA and time slot registers. The control, interrupt, and data input/output registers in the lower right of the diagram provide handshaking with the CMPI. In this case, we chose the QuickLogic QL12x16B 2000-gate FPGA in a 100-pin TQFP package. It has 192 logic cells, each with a register, and 88 I/O pins; therefore, it provided more than enough registers and pins for this design. We were familiar with this part because we had used it for a previous project that had required very high performance. We also found that the part was very flexible. During that earlier project, some experimenting with the software showed that this FPGA could hold pin-outs when the design was changed, and it continued to automatically provide 100 percent routability.

Sid Gilbrech is a senior hardware design engineer working in the Network Systems Division at 3Com Corp. (Santa Clara, CA). He presented this paper at Design SuperCon '96.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  March 1996