Re: [myhdl-list] GSoC'16 | JPEG Encoder

[Christopher F. <chr...@gm...>]

On 3/2/2016 7:24 AM, Henry Gomersall wrote:
> 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.

In my opinion this is all do able, one has to decide
how they want to manage this in their design.  How does
the information permeate to submodules (sub-sub-sub).

>
> 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.

"can be just used" on whatever hardware is best supported
(most portable) when you have generic HDL without specific
primitives.  You can guide the HDL so the synthesizer
infers the correct primitives e.g. DSP blocks can safely
be inferred when the correct widths, delay slots, etc.
This could be controlled with a couple parameters and the
HDL could be modular to fit various structures - maybe?

>
> 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].
>

This is all good but I doubt the students will get to this
level of optimization.  They will be striving for functional
correctness and reasonable performance (no performance
requirement).  If done correctly, a complete set of tests,
playing exploring optimizations and refactoring for performance
should be straightforward.

Regards,
Chris