FPGA Q&A: Actel

March 15, 2007
Electronic Design held a series of Q&A sessions with several major FPGA companies. Here, our roundtable discussion with Actel included Martin Mason, director of silicon product marketing, and Jonathan Alexander, senior manager of applications. Questi

Electronic Design held a series of Q&A sessions with several major FPGA companies. Here, our roundtable discussion with Actel included Martin Mason, director of silicon product marketing, and Jonathan Alexander, senior manager of applications.

Question: What are the top five to 10 issues your applications engineers deal with on an ongoing basis? How are the problems handled at the customer level, and how are they addressed by the company as a whole?

Answer: We see a number of issues when users perform JTAG testing or programming through TAP interface. Compared with the logic complexity and speed of most modern applications, the TAP interface and instruction set is very simple and slow. This leads customers to take signal integrity for granted at the TAP interface, even if other signals are properly terminated elsewhere in the design. Although the data and clock rates are slow, edge rates are as fast as any other signal, so proper termination is a must.

Although we offer many variations of intellectual property (IP) cores, we do help users to customize bus widths, signal polarities, etc. While our IP has been flexible enough to accommodate most requests, this has been a manual process. We’ve recently begun to add this customization capability directly in CoreConsole, our IP deployment platform, and will continue to expand this functionality for more cores in the future. (More information on CoreConsole can be found at www.actel.com/products/software/coreconsole/.)

We see a lot of users planning for SSO/SSN mitigation. Actel has invested heavily in SSN/SSO characterization and verification, and we are able to provide users with world-class level of documentation and support for such inquiries.

There is a broad range of needs for IP integration.

Question: What flow do you suggest your customers follow when starting a new FPGA design?

Answer: Design capture is traditionally done with either language (e.g., HDL) or graphically with schematics. The higher the level of abstraction the design is captured in, the more tool intelligence is required to automatically infer and compile and implement the design. Actel supports all of these different design styles and tool flows using a combination of internally developed and leading edge OEM and third-party tools.

Another design consideration is whether to create your design from scratch, versus leveraging existing private or commercial IP. High-quality IP cores allow for faster time-to-market. Actel invested heavily in developing and supporting both internally developed and third party IP cores. Our Libero IDE has many features to help designers find and use IP efficiently. Actel also created proven system-level reference designs as a starting point for designers to customize from, complete with HDL code, software driver, and or application code, and sometimes even pc-board (PCB) design files.

Question: What is normally suggested to your customers regarding the handling of I/O signal assignments? In what order do you suggest the various signals types be assigned? (That is, start with VREF, move to high-speed I/O, and so on.)

Answer: In order to respond, let’s assume the customer is using an Actel flash-based ProASIC3E FPGA. It contains eight dedicated I/O banks, each of which can be subdivided into five mini banks. The dedicated I/O banks share supply voltages (VMV for inputs, VCCI for outputs, and GNDQ). The mini banks are user-defined groups of I/Os that share a common VREF within a dedicated I/O bank. Only I/Os that share supply voltage and VREF can be placed within a dedicated bank.

First, lay out the dedicated I/O banks. The I/O Bank Assigner tool in Actel’s Designer software will automatically configure the I/O banks for a design. If the user wants to customize the bank configurations, it can be easily done using the PinEditor GUI or using a PDC constraint script. When laying out I/O banks, it’s important to keep SSOs in mind. Switching buses should be spread out as much as possible across the die and placed far away from phase-locked-loop (PLL) supply pins and asynchronous inputs and outputs. After the dedicated I/O banks are laid out, the user can start assigning I/Os. Drag and drop I/Os to the appropriate banks using the GUI, or make the assignments in a PDC constraint file. Differential I/Os require adjacent N/P pairs, so it’s recommended to place these first. Next, place voltage-referenced I/Os and the associated VREF pins, which can be configured from any bonded I/O. All other single-ended I/Os can be placed last.

Question: What approach do you suggest to your customers when dealing with incompatible I/O standards, different voltage references, and other issues with respect to bank or region compatibility?

Answer: Actel has gone to great lengths to simplify the I/O assignment process for users within the Designer software environment (see question above).

Question: How do you tell your customers to prepare for a migration path to another FPGA, a structured ASIC, or an ASIC?

Answer: Uniquely, Actel has offered pin-compatible migration capabilities between multiple generations of flash-based FPGA devices (ProASIC to ProASIC Plus to ProASIC3). To migrate, customers have to design for the newer technology. Then, the designer can drop in the lower-risk mature device (technology) suitable for starting design/deployment. This also gives customers an easy, predefined migration path to a lower-cost solution that requires minimal system and design rework (typically only resynthesis, layout, and retiming) for volume production. This cost-migration strategy allows customers to avoid the risky and costly path to ASIC/Standard Cell.

Question: What advice do you give to your customers when integrating their FPGA device to the PCB with respect to SSO/SSN? Decoupling? Routability? Escape area and escape planning with respect to signal layers? Thermal issues?

Answer: As customers need to better understand and account for SSN characteristics, we have invested heavily in this area. Through testing, characterization, and experiences working with customers, we found the primary contributors to SSN issues are package selection, I/O placement, and output timing. Proper decoupling, termination, and layout on the PCB are important. However, it’s best to prevent SSN altogether from the source of the problem.

QFP packages are inferior to the various BGA packages available due to increased inductance through the package pins and bond wires. As a result, our SSN recommendations are more stringent for QFP packages. To prevent SSN even on QFP packages, avoid placing large groups of SSOs near each other on the die. However, if this is unavoidable, users should make sure that sensitive “quiet” I/Os are placed near VCCI or GND pads. Or, users can space SSO buses away from sensitive I/Os with relatively inactive outputs. If I/O placement is locked, and users aren’t able to satisfy our recommendations, they can create small timing groups within the bus. Here, the I/Os are staggered in timing by more than 1 ns. If this is done, the bus outputs will no longer be simultaneously switching.

Question: Do you provide specific advice for dealing with differential signals? If yes, what is it?

Answer: Our differential I/Os comply with industry specs, and we recommend a standard termination scheme.

Question: How do you recommend global and local/regional clocking be handled?

Answer: Our flash-based ProASIC3E FPGA family offers 18 dedicated globals, which means most designs will not be clock-limited. For regional clocking, 12 of those globals are localized to a quadrant of the device. So, how do FPGA designers handle common globals across user and IP blocks? Typically, the user must instantiate a global in the lower-level block, bring it to an output port, and then distribute to the rest of the design. With Actel’s Libero IDE 7.3, block-based design methodology is available, remedying the clock-distribution problem. Users only need to instantiate a global clock placeholder (CLKINT). Then, the global buffer can be built into the top level of the design. This makes clock assignment and distribution much more intuitive and simplifies the reuse of blocks across multiple designs.

Question: What issues are you seeing with combining IP blocks? What advice can you give for engineers shopping for IP?

Answer: IP creates boundaries and limits what automation tools can optimize. On the other hand, leaving IP boundaries discernable is very useful for debugging. For an incremental design flow, IP blocks are a natural boundary to limit change.

Modern FPGAs have lots of fixed resources beyond the logic gates. These resources can often be shared between multiple IP blocks. Few FPGA vendor tools can optimally deal with this resource sharing. The Actel Libero IDE was designed with this capability in mind. One example is the efficient sharing of the clocking and memory resources between multiple IP blocks on the Actel Fusion mixed-signal FPGA.

When selecting IP, examine the functionality and configurability to see if the IP fulfills design needs. Look at whether the IP is designed for the FPGA architecture you’re targeting, and whether it’s efficient in size and performance. Good IP also comes with thorough testbenches and high-quality documentation. Finally, check IP core heritage as well as the supplier before you commit usage.

Question: What sorts of timing issues are causing the biggest problems, and how do you suggest they be handled?

Answer: Min delay and hold-time analysis seem to be often overlooked. External hold-time and cross-clock domain paths, not simple register-to-register data path versus clock-skew timing, tend to cause the majority of timing issues that cause hardware failures. First, users should perform both back-annotated timing simulation and static timing analysis. Simulation provides functional verification, but static analysis offers the best timing coverage. For accurate external hold calculation, timing should be extracted for the transmitter, the receiver, and the PCB in the best-case operating condition (which consists of highest voltage, lowest temperature, and fastest process). Actel’s SmartTime timing analyzer allows users to enter external input and output delays, and then performs all of the calculations.

The main issue we see with cross-clock domain paths is inadequate timing verification. Static timing analysis is essential when cross-clock domain paths exist in the design. But, some static timing-analysis tools don’t automatically perform this analysis. To perform the analysis, users must define the frequency of each clock, perform the analysis in best- and worst-case operating conditions, and for each operating condition, evaluate timing with maximum and minimum offset between the clocks.

Question: Do you have any recommendations for FPGA engineers working with other members of their team, like the layout engineer, systems engineer, and so on? What team approach should be applied to complex and/or high-speed FPGA designs?

Answer: For more complex FPGA design projects, revision control, incremental design, and design reuse are needed—whether the customer is a one-person company or multiple-person design team. Actel’s Libero IDE is designed with these needs in mind. Unlike other vendors using proprietary-version control schemes, Actel finds most customers prefer to use the same development tools across different functional groups. We support customers using the popular commercial tools such as Rationa Clearcase and open-source CM tools, such as RCS. We also have customers who use in-house source and document control systems successfully.

Another important aspect of team development is to automatically build designs when design changes happen, and to reduce manual synchronization and intervention. Libero’s TCL-based scripting interface allows our customers to build batch scripts effectively for that purpose.

Question: How do you help your customers get from concept to manufacturing?

Answer: We deploy a number of different capabilities to ease the development process:

  • Solutions and reference designs
  • Quick-start tutorials and starter kits
  • Risk-reducing migration capabilities
  • Easy-to-use, comprehensive integrated design environment
  • World-class technical support and documentation
  • Unique risk-reducing migration capabilities

Question: Are you working with EDA companies to better define up-front constraints that ideally could be applied and live with the FPGA throughout the design process?

Answer: As the EDA tools get smarter, and the level of design abstraction rises, designers can lose control of the design when the tools don’t supply the desired results. Therefore, constraints are added to return the control to users. Sometimes, these constraints can get so complicated or obscured, users won’t be able to use them properly. Instead of reinventing proprietary constraints formats, Actel was the first FPGA vendor to fully embrace standards, such as SDC, to ease our customers’ learning curve. The same format is used throughout the Actel tool flow. We also work with our EDA partners to leverage industry-standard constraints to produce space, speed, and power-efficient designs on Actel devices.

Question: What additions or modifications are you making to your tool suite to help engineers overcome the issues discussed above?

Answer: Today, designers can implement a fairly complex system-on-a-chip on modern FPGAs. To unleash the power of an Actel mixed-signal Fusion programmable-system-chip platform, for example, designers require features from traditional logic design tools, as well as features from analog, DSP, and processor design tools. To support customers across functional engineering disciplines, we offer familiar tools so that they can cross disciplines with ease.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!