By: Patrick Chase (patrickjchase.delete@this.gmail.com), February 1, 2013 1:06 pm
Room: Moderated Discussions
Richard Cownie (tich.delete@this.pobox.com) on February 1, 2013 12:32 pm wrote:
> 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
Yep, also the Cadence Palladium line. The big issue is that those cost close to a million a seat when all is said and done, so they're not really cost-effective for general development work. If you have a large developer community to support then you end up with fpga-proto boards and/or software solutions like Mentor Seamless.
That would be epic overkill for a cache-sizing experiment :-).
-- Patrick
> 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
Yep, also the Cadence Palladium line. The big issue is that those cost close to a million a seat when all is said and done, so they're not really cost-effective for general development work. If you have a large developer community to support then you end up with fpga-proto boards and/or software solutions like Mentor Seamless.
That would be epic overkill for a cache-sizing experiment :-).
-- Patrick
