FPGA Q&A: Lattice Semiconductor

Electronic Design held a series of Q&A sessions with several major FPGA companies. Here, our roundtable discussion with Lattice Semiconductor included Bertrand Leigh, director of applications engineering, and Mike Kendrick, software product planning manager.

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:

Meeting hardware timing requirement: High-level evaluation of specification and whether or not it meets the system requirement. For example, if the system requirement is 1.2-Gbit/s I/O, but the FPGA I/O can only support 800 Mbits/s, the FPGA will not meet the system speed requirement.
FPGA design timing closure: Running sufficient-enough static timing analysis and timing simulation to ensure that the HDL design will meet the hardware setup-and-hold timing requirements. Having pre-engineered hardware blocks, such as DDR Memory I/O interface and SERDES/PCS blocks, helps the FPGA designer more easily meet timing and there’s less burden on the software tool. These hardware blocks are available in our low-cost LatticeECP2/M FPGA family as well as the high-end LatticeSC FPGA.
SERDES implementation in the system: Although conceptually simple, the hardware implementation requires very detailed conditions on signal termination, generation of reference clock, use of phase-locked loop (PLL), and evaluation of backplane signal integrity and bit-error rate. Lattice provides predefined SERDES demos targeted for different SERDES applications, such as PCI Express and generic 8/10-bit SERDES loopback hardware demo platforms.
PCB and FPGA noise management: Pin assignments to meet the PCB and FPGA noise margin. Lattice is committed to providing high-quality signal-integrity design capabilities, such as HSPICE and IBIS I/O buffer models. The following links will take you to the Lattice IBIS (www.latticesemi.com/dynamic/index.cfm?fuseaction=view_category&document_type=37&source=topnav) and HSPICE (www.latticesemi.com/dynamic/index.cfm?fuseaction=view_category&document_type=133&source=topnav) pages/documentation.
Handling designs with multiple clock domains: How to map to the FPGA and properly analyze timing.
Power management: Power budgeting for all FPGA power supplies. Typically, there are two or three FPGA supplies (VCC, VCCAUX, and VCCIO) that are critical. Accurate estimation for initial power-up and at temperature during device operation is needed.
Power sequencing requirements: What sequencing is required to properly bring up the FPGA?
Configuration requirements: This critical step ensures that the FPGA would configure correctly from the external “boot” flash after power-up.

At the customer level, designers have to rely on the documentation and software tools from the FPGA vendor. From the Lattice standpoint, we need to be sensitive to such critical information and tools and make them as accurate and as user-friendly as possible. In addition, we need to make use of the Web-based communications tools, such as Forums/FAQs, to supplement traditional phone and e-mail communications to help customers.

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

Answer:

Software flow would include low-cost (free) OEM starter software like ispLEVER-Starter software using HDL design flow. This would get you to running static timing analysis to obtain a sense of how fast the customer’s design would run. If needed, timing simulation tools like ModelSim should be used.
From the documentation standpoint, any available datasheet and application note relating to the specific product would be helpful. Also, reviewing the IP designs that are either generated by the FPGA vendor or third-party partners would give the user a good sense of what kind of speed can be achieved for a similar function.
You can also look into the available evaluation boards for a given FPGA product family to initiate the hardware validation.
Once the FPGA vendor and software tool are selected, the user must determine a particular FPGA density in lookup-table (LUT) counts and feature set (i.e., SERDES, PLL, DSP block requirements).
Use of good design practices like fully synchronous design, design partitioning, functional and timing simulation, and proper pin assignments from the complete design would improve the chances for first-time success.

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:

FPGA I/O structures are more complex than your standard product with fixed I/O pins. It requires proper I/O floorplanning to make sure that, first, the assigned I/Os don’t have any conflicts to coexist within a bank, and second, they will run at the required I/O speed without noise or signal-integrity issues.
Start with the specialized I/O first. For example, DDR2 memory interface, SERDES interface, PCI interface, etc. This will determine the critical pin assignments.
Then fill the remaining pins with the general-purpose I/O pins, such as LVCMOS33, LVCMOS25, LVTTL, etc.
Also, pay attention to the special pins such as VREF, high-speed CLK inputs, and PLL/DLL inputs. Users can either specify which device pins to use or have the tools pick the required pins. In the latter case, the user needs to back-annotate these pin assignments so that subsequent PAR runs continue to use the same pinout.
ispLEVER has two basic features to support this:

The Design Planner tool supports the user, creating I/O placement constraints that meet complex I/O banking rules. From the Package View, the user can visually filter for the available pins that have certain characteristics (e.g., primary clock input pins, differential pin pairs) and then assign design signals to this filtered view of pins.
I/O Assistant Flow allows the actual PAR engine to be used on just the I/O ring of the design (along with user-provided I/O placement constraints) to create a legal I/O placement. This can be done earlier in the design flow to allow earlier board design.

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:

Typically, an FPGA will have up to eight I/O banks. If the pin assignments method in item 3 is followed, the bank and region conflict will be minimized.
There’s a hard limitation based on the hardware requirement. FPGAs are made to be flexible, but beware of the hardware limitations and plan ahead so that you’re not painted into a corner in the last stages of your PCB design.
The ispLEVER I/O Assistant design flow methodology assists users in selecting a device pinout early in the design-flow process. The goal of the I/O Assistant design flow is to produce an FPGA-verified pinout based on limited design knowledge and broad board layout requirements.
I/O standards typically follow the VCCIO. The unique aspect of Lattice FPGA is that the output standard follows VCCIO, but one can mix certain input standards that differ from the VCCIO. For example, VCCIO at 3.3 V is used for LVCMOS33, but the LVCMOS12 (1.2V) input standard can be placed in the same bank.

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

Answer:

It’s easy enough to plan for density migration within an FPGA family. Select a package that has the density points you require.
Write your HDL code as portable as possible for ASIC migration if this is the intention.
An intermediate step toward ASIC is the low-cost production FPGA flow, such as FreedomChip from Lattice and other available migration paths. The FreedomChip (www.latticesemi.com/products/fpga/sc/freedomchip.cfm) page and paper FreedomChip A COST REDUCTION METHODOLOGY FOR Lattice SC/M DEVICES (www.latticesemi.com/documents/WP-FreedomChip.pdf) provide additional details.
No direct path from FPGA to ASIC is available.
Similarly, when a customer wants to migrate between FPGA vendors, the code must be portable. Any functional blocks that are tied to hardware features (such as a particular embedded memory block, PLL/DLL, and DSP blocks) will have to be manually converted.

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

Answer:

There’s a certain PCB design methodology one can follow to minimize the effect of SSO noise. The methodology consists of distributing the capacitive loads and pin assignment, optimizing the drive current, controlling output slew rate, and reducing the output voltage swing if possible.
Decoupling examples based on evaluation boards and recommended documentation.
Routability for both the PCB and FPGA? Not many issues with FPGA routability unless the device’s utilization is high (>75%).
The BGA packaging general rule-of-thumb for PCB escape planning includes two signal layers for every two concentric rows of balls if all signals need to be accessible.
Lattice provides an accurate, software-based power estimator and package thermal impedance to accurately predict potential board-level thermal issues.

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

Answer:

Detailed ac- and dc-coupled termination schemes are provided for different differential standards, such as CML, LVPECL, and LVDS, especially for data rates in the 600-Mbit/s to 3.5-Gbit/s range.
Also, general differential PCB layout rules apply to keep equal trace lengths between the P and N side of the differential and between the data channels of the transmit and receive sides of the differential interface.
Several Lattice application notes can guide customers through their PCB designs. The documents discuss PCB routing and stack-up as well as termination scenarios. These guidelines help customers avoid some of the pitfalls they might otherwise encounter while doing high-speed circuit design and layout. Application notes include: Electrical Recommendation for SERDES (www.latticesemi.com/documents/TN1114.pdf) and High-speed PCB design considerations (www.latticesemi.com/lit/docs/technotes/tn1033.pdf).

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

Answer: There are three general clocking schemes available on Lattice FPGAs:

Primary (or Global) clock is used for a clock that’s distributed to the entire FPGA. This is a low-skew clock that reaches all registers in the device. Because it reaches all resources, one drawback is relatively longer clock injection time. On-chip PLL could be used in combination with the Primary clock to minimize the clock injection time.
An intermediate Secondary clock is used for a clock resource intended for localized resources. Since it’s localized, the Secondary clock has the benefit of shorter clock injection time. Also, there’s smaller clock skew for the localized area so that the overall clock speed can be faster. On-chip PLL could also be used for this clock.
Edge (or I/O) clock is used to clock the I/O registers with the lowest clock injection time and to achieve the best I/O register setup and hold time. Built-in clock dividers are available for the FPGA I/O data-transfer Edge and Primary clock. The clock divider will adjust the high-speed serial-data-clock speed to slower-speed parallel internal data clock through gearing in the I/O logic.

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

Answer:

Achieving the required IP timing is one of the challenges when combining IP blocks.
To minimize this challenge, make sure that the IP block is properly validated with static timing analysis, timing simulation, and hardware validation as necessary.
Pay attention to how easily a given IP block meets timing. What speed-grade FPGA device is needed to achieve the advertised speed of the IP block? This is an indication of the amount of timing margin for a particular IP block.
The Lattice IPexpress tool allows the customer to “test drive” the IP in hardware with a timed license before committing to purchase the IP.
Most IP cores require some form of common Control Plane Interface (CPI). IP development methodology with a common CPI allows customers to efficiently define interfaces and software drivers to their host controller. To provide an easy-to-use, extensible, and portable CPI that will be designed in all future IP cores, four issues must be addressed:

IP design methodology
Provide a common CPI architecture that’s easy to use
Provide a software-agnostic interface so that the customer software/API will seamlessly interoperate with the hardware
Incorporate a Multi-Master configuration whereby a local host, JTAG, or some other form of Control interface can source processor bus transactions.

By providing a common IP Design methodology, developers follow a common control interface philosophy. A common CPI architecture lets customers become familiar with an easy-to-use interface. This also reduces the amount of “churn” between engineers as they decipher how an IP’s CPI operates. Lattice is aware of this requirement and is working toward this methodology.

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

Answer:

Clock domain transfer at high speed
Race condition
Hold-time violation

Timing windows are getting smaller with higher frequencies. A combination of careful timing analysis along with the software tools’ capability can help identify the areas and resolve the issue.

Due to the extremely high performance of the Lattice FPGA fabric, the probability of hold-time violations has significantly increased. Hold-time violations generally occur when the clock skew is greater than the data delay. Even though the Lattice FPGA’s primary clock routing has very low skew, the data routing is so fast that these types of violations are possible. Lattice’s ispLEVER design tool provides the ability to automatically correct hold-time violations.

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:

Proper FPGA design partitioning should be done with the system engineer.
Pinout floorplanning should be done with the layout engineers.
Check points with proper design reviews are needed to ensure that the functional block and pinout in the FPGA will work in the end system.
I/O Assistant Flow (mentioned earlier) allows earlier collaboration between design and board layout. It’s recommended if the design uses a mix of I/O standards that may be challenging to fit into the I/O banking rules.

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

Answer:

FPGA evaluation boards can help validate critical functional blocks in hardware
Plan ahead for power and configuration for manufacturing
Runtime/turnaround time improvement for complex designs

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:

PCB EDA vendor: allows board layout and FPGA pin assignments to be kept in sync from the PCB tools to the FPGA design tool; signal integrity and I/O planning for efficient PCB routing.
Synthesis: have enhanced ability to pass constraints from ispLEVER to synthesis tools; currently, design-specific constraints are entered independently into synthesis and ispLEVER with a loose connection available. We’ve found users often want to constrain synthesis and backend differently.

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

Answer:

Power planning
SSO planning
FPGA constraint planning
Runtime/turnaround time improvement
Design debugging tool – Lattice ispTRACY Usage Guide (www.latticesemi.com/lit/docs/technotes/tn1054.pdf)
Prebuilt IP that enables (silicon-based) timing correct, function for high-speed interfaces
RTL Analysis – improving RTL quality and documentation Lattice HDL Explorer (www.latticesemi.com/corporate/newscenter/newsletters/newsjanuary2007/isplever6.1.cfm)