Re: GSoC'16 | JPEG Encoder

On 02/03/16 15:16, Martin Strubel wrote:
>> I wrote an inline complex multiplier based around a single DSP which
>> > really gets into the guts of the DSP core. It's hard to see how one
>> > would do this in plain VHDL with a hope that it would be inferred
>> > correctly (the difficulty is in things like flicking control registers
>> > mid pipeline from multiply-add to multiply-accumulate to
>> > multiply-deccumulate).
>> > 
> I never had troubles getting the right thing instanced when staying
> below the 18 bit of the classic multiplier primitive. Above that, it can
> get funky on some toolchains WRT timing, but the nice thing about MyHDL
> is that it allows you to swap out the primitives in a much more
> configurable/reusable way than on the VHDL level.
> For the pipeline control, I typically use VLIW microcode that can be
> adapted easily if one of the MAC primitives needs to use a higher delay
> within the pipeline. So on the high level 'synthesis', you spell out the
> ops done in the pipeline in Python and the architecture (FPGA vendor)
> specific translator rolls out the rest. So a DCT is just a "hardware
> applet". If you spell it out in pure (vendor independent) VHDL, the
> synth tools always did it right so far, it just wasn't always optimal
> for their architecture and this is where the manual optimizations get
> nasty and way less reusable than in MyHDL.

I don't fully understand what you're getting at, but I think your
suggesting much the same as me :)

What do you mean my VLIW microcode? Why does it need to be VL?

Cheers,

Henry

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