Re: GSoC'16 | JPEG Encoder

On 02/03/16 12:06, Christopher Felton wrote:
> The students will not be starting from scratch, they will be
> using existing open-source encoders [1] to "port".  But this
> will not be a simple port, they will be creating a design that
> is more modular, scalable, and reusable than the existing
> version.  As well as having a more exhaustive set of tests.

Something just came to mind in light of this. I do wonder if it would be
useful to have some mechanism by which inner primitive blocks can be
switched.

Specifically, most FPGAs have various mutually incompatible primitives,
things like DSPs and RAM blocks. It would be great, for example, to have
a MyHDL DSP structure that can be _just used_, and then switched to
support whatever hardware.

Clearly, this sort of goal fits within something like rhea, but I'm not
sure if there is an explicit drive towards it.

In many instances, the primitives can be inferred from the V*, but more
complicated designs (e.g. a JPEG encoder) can be made more efficient of
resources by time slicing primitives, something the synthesizers are not
good at [1].

FYI, I've done some work on a Xilinx DSP and RAM block.

Henry

[1] as an aside, Xilinx have a beautifully well designed FIR block in
Vivado which does exactly this - it will time slice the DSP blocks for
you based on throughput clock speed, using the fewest DSP primitives it
can get away with.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140