Re: EXTERNAL: [vhdl-200x] Regarding Matrix Math Users' Guide proposal

Hi Martin and Andy,

  I am also supportive of its inclusion. I was just concerned with the
inclusion of compute operations. My point was that the current
implementation (as in the package) of these matrix functions are good for
testbench but may not be so appropriate for synthesis. Nevertheless,as you
guys mentioned, I do see a value in this being a reference for other manual
implementations.

Thanks!
Sharad




On Tue, Oct 1, 2013 at 4:12 PM, Martin.J Thompson <Martin.J.Thompson@trw.com
> wrote:

>  I was going to write an email on exactly the same lines, but Andy beat
> me to it!****
>
> ** **
>
> Cheers,****
>
> Martin****
>
> ** **
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Jones, Andy D
> *Sent:* 30 September 2013 17:57
> *To:* vhdl-200x@eda.org
> *Subject:* RE: EXTERNAL: [vhdl-200x] Regarding Matrix Math Users' Guide
> proposal****
>
> ** **
>
> Sharad,****
>
> ** **
>
> As a precedent, the standard already defines the division operator for
> many synthesizable data types, including fixed and floating point, yet
> except under specific, statically constrained circumstances, division is
> not synthesizable either. ****
>
> ** **
>
> Multiplication in general is synthesizable, but not guaranteed to meet
> performance requirements for an arbitrary operand size, clock rate and
> target technology. ****
>
> ** **
>
> Some synthesis tools allow the user to describe additional clock cycles of
> latency (empty registers) before/after a multiply operation, and then to
> instruct the synthesis tool to pipeline the implementation across the
> provided clock cycles (registers).  This is used, when enabled, to
> automatically assemble and pipeline multiple built-in synchronous
> multipliers/adders to implement a wider and/or faster multiplier than is
> otherwise available in the target technology.****
>
> ** **
>
> In a similar manner, a multiply operator for a matrix data type is
> potentially synthesizable by a synthesis vendor, if provided with
> sufficient clock cycles over which to pipeline the implementation.****
>
> ** **
>
> Even in the absence of synthesis, these operators provide behavioral
> reference models (just like the existing division operator for existing
> synthesizable data types) that are synthesizable for static purposes (e.g.
> calculation of a constant or generic matrix value) and useful for
> verification of manual design implementations.****
>
> ** **
>
> Furthermore, if these operations were provided only as unique, long-hand
> functions or procedures, rather than operators, the likelihood that they
> would be eventually supported by synthesis is reduced.****
>
> ** **
>
> Therefore, I support the inclusion of these matrix operators in the IEEE
> package.****
>
> ** **
>
> Sincerely,****
>
> ** **
>
> *Andy D Jones
> *Electrical Engineering****
>
> Lockheed Martin Missiles and Fire Control
> Dallas TX****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org<owner-vhdl-200x@eda.org>]
> *On Behalf Of *Sharad Sinha
> *Sent:* Sunday, September 29, 2013 3:05 AM
> *To:* vhdl-200x@eda.org
> *Subject:* EXTERNAL: [vhdl-200x] Regarding Matrix Math Users' Guide
> proposal****
>
> ** **
>
> Hi group,
>
> * Please ignore this if you have already received it*****
>
> ** **
>
> This review comment is relevant to Matrix Math Users' Guide IEEE Package
> proposal. I had an offline discussion with David, who proposed
> this, regarding this and I felt it might be appropriate to see what others
> think.
>
> I looked at the package code and the user guide. Everything seems to be
> useful. My only concern with the package is that it also includes functions
> for computation operations on matrices. I think that the existing
> implementation of compute functions (like multiply etc.) will be more
> relevant for testbench than for synthesis.
>
> When compute operations are included in the package, from a synthesis
> perspective, a designer loses control. Calculations like matrix multiply
> done using loops (in the package) do not allow a designer using the package
> to maximize parallelism. Also, a designer won't be able to assign a
> synthesis directive if he/she wanted. Of course it might be possible to
> edit the package locally but then that is basically against the principle
> of using a package in the first place.
>
> I would say that functions which manipulate data arrangement in matrices
> or move data in and out are better suited for a package compared to compute
> functions (*, /, ./, +, - etc.). Also, leaving the implementation of these
> operators to the mercy of synthesis tools might generally be a good idea
> but is not so always.****
>
> ** **
>
>
> Regards,****
>
> Sharad****
>
> ** **
>
> ---------------------------------------****
>
> www.sharadsinha.wordpress.com****
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.