FPGA-based prototyping 3: Which board do I need?
Part three of our series looks at the choices you face as you decide whether to build or buy a board.
FPGA prototyping
FPGA-based prototyping 2: Understand the real cost
Part two of our series on FPGA-based prototyping looks at two critical factors to address before a project begins: budgeting and high-level implementation.
Skeet shooting and design debug
In-circuit emulation is attractive but brings with it debug-visibility issues. There are ways to restructure the environment to make bug hunting much more deterministic.
FPGA-based prototyping 1: What’s all this buzz about?
This multi-part series addresses various aspects of FPGA-based prototyping. Future installments will address budgeting and implementation, but we start by looking at why the technique is generating so much interest.
Why emulation performance doesn’t matter (on its own)
Emulation performance is a key metric in verification. But it is far from being the only consideration. How long it takes to get a design onto a verification platform and aspects such as debug are as important. These factors will control how verification platforms are deployed during a project's life cycle.
Building better debug facilities for bigger FPGA-based prototypes
The introduction of bigger FPGAs enables more complex prototypes - but makes debugging more of a challenge. Here's one way to address the issue.
Enabling FPGA prototyping of large ASIC and SoC designs
How tool parallelism, automatic partitioning, deep debug memories and time domain multiplexing eases FPGA prototyping of large ASIC and SoC designs
Developing and integrating configurable GPU IP using FPGA-based prototyping
How Imagination Technologies used FPGA-based prototyping to develop its GPU IP and integrate it into a real world system
Accelerating ‘time to prototype’ with ProtoCompiler
A look at a tool and a flow that makes it easier to put designs on to a HAPS physical prototyping system for verification, debug and software development purposes
Early tape-out: smart verification or expensive mistake?
Is it worth trying to iron out all the bugs in an SoC before taping out, or should design teams anticipating a re-spin go to silicon earlier and use the chips that come back as verification accelerators?