Patrick Chase (patrickjchase.delete@this.gmail.com) on January 30, 2013 10:36 pm wrote:

> People who design SoCs use FPGAs all the time, mostly to enable software/firmware co-development
> (i.e. the firmware is developed in parallel with the HW, using an FPGA to emulate the SoC). There
> are a couple issues that come into play when it comes to performance modelling, though:
>
> 1. Modern SoCs are often too big to fit into a single FPGA (even the $10000+ kind), so you end
> up having to either simulate a subset of the SoC or partition across multiple FPGAs. If you
> do the former then you end up nonrepresentative bus and memory loads. If you do the latter then
> you typically end up muxing multiple signals onto each of your limited set of FPGA I/Os via
> serdes, and then you end up running slow (or with compromised timing relationships).
>
> 2. A CPU core that would synthesize at 1 GHz in a modern SoC process/library might run at a couple hundred
> MHz at best in a single top-end FPGA (I'm not pulling these numbers out of thin air :-). At that point
> the timing relationships between the core, fabric, and memory subsystem end up completely whacked
>
> 3. The memory controller that's available "off the shelf" for the FPGA seldom behaves like the
> one you'll use for your SoC, which goes back to your point about fidelity of memory modelling.

I'm familiar with Mentor's Veloce/Veloce2 fpga-based emulation system - it solves the
timing-modelling issues and multi-fpga partitioning that you mention, and gives
a bunch of other useful functionality as well (e.g. visibility of all signals) - but
costs a lot more than fpga-prototyping boards, and typically runs the
emulated user clock at < 2MHz. It gets used a lot for SoC developments.