X P L A N AT I O N : F P G A 1 0 1

A Framework for
FPGA Design Planning
by Jeffrey Lin
Senior Manager, Global Communications Services Group
Xilinx, Inc.
[email protected]

This time-tested
FPGA development
framework is your
route to flawless
project execution.

46 Xcell Journal Fourth Quarter 2014

T
XPLANANTION: FPGA 101

FRAMEWORK OVERVIEW At this level of discussion, only the

The framework is an iterative, top- general outline of the FPGA features is
down methodology for designing hard- required. The detailed features and im-
ware in FPGAs. First, the planning plementation requirements will be de-
starts at the system architecture level fined in a later stage during the FPGA
to determine FPGA functionality. Then requirements definition. Participants
we progressively refine the features in this discussion should include some-
implemented in the FPGA using the one familiar with the system-level re-
known capabilities and performance quirements, someone with system-lev-
of the FPGA device. el architecture design knowledge and
In addition, the implementation someone familiar with the features and
of large FPGA designs necessitates capabilities of FPGAs.
well-defined development, simulation In the context of the FPGA, there
and verification plans. The framework are 10 important questions to answer.
aids us in crafting those plans as well.
1. What is the feature list to be imple-
The capabilities and performance of In short, the framework can be sum-
mented in the FPGA?
modern FPGAs have long since reached marized as shown in the flow chart in
the point where these devices now sit Figure 1. The focus for this discussion 2. What are the technical trade-offs for
in a central location within systems and is on the Planning and Documentation implementing features in the FPGA
serve as a primary data-processing en- portion (top section). vs. using non-FPGA components?
gine for many products.
3. What is the design effort/cost to
Given the important role FPGAs SYSTEM ARCHITECTURE
implement in FPGA vs. non-FPGA
play in so many applications, it is In the context of this discussion, sys-
components?
more important than ever to approach tem architecture refers to the divi-
FPGA design with a formal and me- sion of functionality among system 4. What custom features or process-
thodical development process. The software and hardware. In particular, ing are required?
purpose of such a process is to avoid the focus is on the subdivision of the 5. 
What does the flexibility of the
costly and time-consuming design de- hardware functionality into FPGA and FPGA bring to the functions?
ficiencies discovered late in the devel- other microchip components, with
opment cycle that can have a poten- the assumption that product-level re- 6. What future-proofing risk mitiga-
tially disastrous impact on schedules, quirements are already defined. For tion should you consider?
cost and quality. example, a marketing or product-defi- 7. Can features be consolidated with-
The Xilinx Global Communica- nition organization may have already in the FPGA from multiple non-
tions Services Group has long been weighed in with product requirements. FPGA components?
using a time-proven design frame- In the system architecture phase,
work to develop and deliver turnkey the idea is to bring clarity to how 8. Based on the design features to be
FPGA designs to Xilinx customers for these product requirements are to be implemented, what are the FPGA
products ranging from medical-imag- realized in a physical product. For the device choices?
ing processing engines to self-learn- FPGA, the primary decision is what 9. Can the features be implemented
ing network switch engines. It is a features and functions should be im- in an FPGA?
framework we have developed and plemented in the programmable de-
evolved over the course of designing, vice and furthermore, what is reason- 10. 
What non-FPGA devices are re-
developing and delivering hundreds ably achievable in an FPGA. quired and how do these devices
of FPGA designs. By defining the high-level require- interface to the FPGAs?
The framework we use covers ev- ments of the FPGA up front, you can
erything from system architecture avoid costly design and requirements FPGA ARCHITECTURE
considerations to FPGA development changes before you have proceeded The FPGA architecture is the microar-
and test planning. Let’s take a closer too far down the development pro- chitecture and chip-level data-flow de-
look at this framework, with a focus cess. At this early stage, the definition sign at the physical level on the FPGA
on the FPGA hardware, in hopes that of the system architecture will guide device. Your team should design this
other engineering teams might find it a you to several important decisions architecture concurrently with the sys-
useful tool for tackling complex FPGA that affect both development time and tem-level architecture for device sizing,
design projects of their own. product cost. selection and feasibility.

Fourth Quarter 2014 Xcell Journal 47

 XPLANANTION: FPGA 101

The purpose of defining the FPGA ar-

chitecture is to ensure the system archi-
tecture requirements can be implement-
System ed with accurate, realistic and achievable
Architecture
design requirements in the FPGA.
This level of discussion requires in-
timate knowledge of the features and
capabilities of the FPGA fabric and re-
sources. It should therefore be under-
FPGA Architecture taken with participants who are expe-
rienced FPGA designers. At this stage
you must consider the decisions for per-
Planning and formance targets of the FPGA, potential
risk areas, as well as available FPGA
Documentaion fabric resource utilization.
Performance During the FPGA architecture defi-
Estimation Exceeds FPGA
Performance
nition, it’s possible you might find that
Within FPGA
the system-level requirements and ar-
Performance chitecture are unachievable or high-risk
for implementation in the FPGA. In this
FPGA case, you must reevaluate and update
Requirements
Definition and the system architecture to create a
Partition set of high-level requirements that are
achievable in the FPGA.
Ask yourself what existing IP can
be used and what must be created. You
also need to examine I/O requirements
and how to map the clock domains and
FPGA Design features onto the FPGA clock resourc-
Planning es. Other key questions include how to
place the GT resources on the FPGA,
whether cross-SLR data flow is ac-
counted for in SSI devices and wheth-
er target clock frequencies are realistic
FPGA Design FPGA Test for the design functionality. Finally,
Development Development
you must also assess whether your tar-
get performance goals are realistic for
Simulation the selected FPGA.
Testing
not Coding and
adequate
FPGA REQUIREMENTS
Simulation DEFINITION AND PARTITION
The FPGA requirements definition-and-
Test
Evaluation partition phase is closely related to the
system and FPGA architecture and is
Simulation driven by the decisions made at those
Testing
adequate
stages. The FPGA requirements defini-
tion refers to the detailed requirements
to be implemented in the FPGA and will
Hardware Test serve as the definitive feature list for the
design and test-engineering teams to
achieve, design and implement. This job
differs from the system and FPGA archi-
Figure 1 – The FPGA development framework tecture requirements in that the FPGA
48 Xcell Journal Fourth Quarter 2014
 XPLANANTION: FPGA 101

requirements are precise. The list defines test platforms and tests to validate In terms of FPGA-specific planning
the minute details of the FPGA rather each requirement with a definitive pass and development, one of the benefits of
than the division of functionality between or fail? FPGAs is the ability to revise and down-
the different components of the system, load a hardware platform to a prototype
or the data flow through the FPGA. FPGA DESIGN PLANNING PCB multiple times. Design teams should
The purpose of this stage is to clearly This stage of the framework is planning for take full advantage of this capability.
define exactly what the FPGA engineer- the actual development of the FPGA hard- Therefore, the recommended develop-
ing team should implement and test. Here, ware and to ensure features and devel- ment plan is one that will incrementally
you will translate the high-level system opment are completed in step with other add features to a working design. The
and FPGA architecture requirements into parts of the overall product development. idea is to start with a basic design that
exact requirements for implementation. The goal at this point is to properly can enable the major communication in-
The benefits of doing this are twofold. map the current state of the system-level terfaces to function without all of the re-
First, discretely defining the FPGA re- and FPGA-level requirements and archi- quirements implemented.
quirements will highlight any limitations tecture into a development plan. After go- The benefits of such an approach are
of the system and FPGA architecture and ing through the previously listed planning twofold. First, you will ensure there is
any previously unconsidered or unfore- stages, there are typically two scenarios always a working design that you can
seen conditions. Second, this step will development teams will now encounter. use to debug a PCB and the larger sys-
pave the way for smooth execution of the Scenario 1 is a case where the sys- tem. And second, debugging the actual
FPGA design development and test. tem and FPGA architecture and require- FPGA design will be easier, since you
To properly outline FPGA require- ments are well understood and are finely can check newly added features to en-
ments, you must have a clear definition detailed, resulting in an FPGA design de- sure they do not interfere or break the
that is concise and easily distilled into velopment phase (that is, HDL coding) currently operational design.
discrete requirements. We recommend and test development phase (simulation In parallel with the FPGA design
labeling or numbering the requirements testbench) that will proceed smoothly development, it is vitally important to
and defining them as a basic descrip- with minimal requirements changes. have a sound simulation environment
tion easily determined to be achieved Scenario 2 is a case where the system plan for the resulting FPGA design. In-
or not, rather than as a high-level, am- architecture and FGPA requirements vesting in the development of a robust
biguous requirement. You can use any are still in flux. Designs in this catego- simulation environment will not only re-
industry-standard or proprietary format ry will encounter multiple changes and sult in a reduction of design bugs, it can
so long as it is clear and concise. revisions during the design and test de- also significantly reduce lab debug time
Avoid vague or loosely defined terns velopment phases of the cycle. by allowing you to replicate real-life
such as “fast” or “small.” Instead, stick While everyone shoots for Scenario data flow so as to reproduce error con-
with specific targets such as “400 MHz” 1, more often than not, people will find ditions in simulation and quickly isolate
or “4.2k flip-flops.” The goal of this themselves in Scenario 2—clearly, a and determine the root causes.
definition is to ensure the document more difficult situation to manage. Development of a robust test and
can be distributed to development en- The overall goal of design planning simulation environment is just as com-
gineering teams with no prior knowl- should be to reach Scenario 1 at this plex as development of the FPGA de-
edge of the system or FPGA architec- stage of the development cycle. In Sce- sign itself and should be planned for
ture to implement without the need nario 1, the development of the FPGA and given consideration as such.
for constant clarification. Ask yourself is straightforward and is a matter of The Xilinx Global Communications
whether each requirement is clear, con- scheduling the implementation and test Services Group has honed our FPGA
cise and unambiguous and whether of design features. development framework through con-
it contains all the necessary informa- In Scenario 2, the most important sistent application over hundreds of
tion to avoid a need for constant clar- management task is to ensure you have a FPGA designs. The result is a practical
ification. Also, do the requirements in- well-understood process in place to eval- design approach that delivers results,
clude pin-out and I/O definition? Are all uate and determine what changes should is easily understood and is widely ap-
high-level requirements decomposed be implemented, and the impact of each plicable to many different develop-
into fundamental design elements? change to the overall development sched- ment tasks. The benefits of using this
Can a design team not involved with the ule. There are several program-manage- framework in developing your next
early system architecture definition use ment philosophies and techniques that FPGA design will be accurate overall
the requirements to develop an FPGA? you can employ here. The most import- development schedules, fast hardware
And finally, can a test and verification ant point is that such evaluation and im- bring-up and, ultimately, an on-time
team use the document to develop pact assessments are made. product launch.
Fourth Quarter 2014 Xcell Journal 49