«

On 15 Mai, 05:13, David Bishop <dbis...@vhdl.org> wrote:
> I've been asked by the 1076.1 (analog VHDL) for a matrix math package.
>
> I put my first cut of a "real_matrix" package on line at:http://www.vhdl.org/fphdl/real_matrix_pkg.tar
> This includes the package, package body and a short testbench. *It still
> needs some documentation, and probably a few more functions.
>
> This is for type "real" only. *Please tell me what you think.
>
> Once we understand what is needed I can also do this with "signed" and
> "sfixed" types.

Hi David,
nice work, helps to fill the big chips more conveniently.
Also makes testbenches more powerful, especially when you use VHDL-
AMS.

But how relevant/useful is it for designers?
Let's just take a look at the simple matrix multiply.
Inside the functions you are looping through the matrix elements and
use the * operator.
Maybe the synthesis tool is intelligent enough to use a predefined
macro or megacell (or whatever it may be named from the vendor),
the number of needed multiplieres grows with a square function
according to the growing size of the matrix.
While handling a 3x3 matrix may be ok, a 8x8 matrix would already
overfrow most chip sizes.
And if it's not the number of multipliers, the routing requirements
will be even more challenging.
Since, when using the function everything is intended to happen
concurrently.

Regards
Eilert

Also, one of the main problems is not even touched: where does the
data come from (and go to after computation)?
Normally one doesn't just need a single operation, but lots of them
according to perform some intended algorithm.
So you have a bunch of data. Normally this will be stored in RAM, to
save chip space.
So, even if you have these nice concurrently working operators, the
bottleneck will be memory access.
Advantage in FPGAs/ASICs is that we can use small chunks of memory
between operations, compared to the one big memory a microprocessor
has to use.


So, this package is a useful language extension for testbenches, and
maybe for some specialized high speed ASIC applications.
For the average design the immense amount of needed ressources makes
it almost useless.

There exist packages for bitserial arithmetic (not standardized,
though), maybe such an approach would also be interesting for matrix
arithmetic.
So the data words could be streamed in and out, using either FIFOs or
RAMs.
While functions like 'times' '+' or '-' could work easily with both
methods, the more complex functions may need extra effort to handle
intermediate results.
Also, such a package would put tight chains to the data format for
matrices and vectors.
Wether this would be a good thing or not, at least the designers will
be liberated from reinventing it for every new design. (design re-use)

On May 17, 1:42*am, backhus <goous...@googlemail.com> wrote:
> On 15 Mai, 05:13, David Bishop <dbis...@vhdl.org> wrote:
>
> > I've been asked by the 1076.1 (analog VHDL) for a matrix math package.
>
> > I put my first cut of a "real_matrix" package on line at:http://www.vhdl.org/fphdl/real_matrix_pkg.tar
> > This includes the package, package body and a short testbench. *It still
> > needs some documentation, and probably a few more functions.
>
> > This is for type "real" only. *Please tell me what you think.
>
> > Once we understand what is needed I can also do this with "signed" and
> > "sfixed" types.
>
> Hi David,
> nice work, helps to fill the big chips more conveniently.
> Also makes testbenches more powerful, especially when you use VHDL-
> AMS.
>
> But how relevant/useful is it for designers?
> Let's just take a look at the simple matrix multiply.
> Inside the functions you are looping through the matrix elements and
> use the * operator.
> Maybe the synthesis tool is intelligent enough to use a predefined
> macro or megacell (or whatever it may be named from the vendor),
> the number of needed multiplieres grows with a square function
> according to the growing size of the matrix.
> While handling a 3x3 matrix may be ok, a 8x8 matrix would already
> overfrow most chip sizes.
> And if it's not the number of multipliers, the routing requirements
> will be even more challenging.
> Since, when using the function everything is intended to happen
> concurrently.
>
> Regards
> * Eilert
>
> Also, one of the main problems is not even touched: where does the
> data come from (and go to after computation)?
> Normally one doesn't just need a single operation, but lots of them
> according to perform some intended algorithm.
> So you have a bunch of data. Normally this will be stored in RAM, to
> save chip space.
> So, even if you have these nice concurrently working operators, the
> bottleneck will be memory access.
> Advantage in FPGAs/ASICs is that we can use small chunks of memory
> between operations, compared to the one big memory a microprocessor
> has to use.
>
> So, this package is a useful language extension for testbenches, and
> maybe for some specialized high speed ASIC applications.
> For the average design the immense amount of needed ressources makes
> it almost useless.
>
> There exist packages for bitserial arithmetic (not standardized,
> though), maybe such an approach would also be interesting for matrix
> arithmetic.
> So the data words could be streamed in and out, using either FIFOs or
> RAMs.
> While functions like 'times' '+' or '-' could work easily with both
> methods, the more complex functions may need extra effort to handle
> intermediate results.
> Also, such a package would put tight chains to the data format for
> matrices and vectors.
> Wether this would be a good thing or not, at least the designers will
> be liberated from reinventing it for every new design. (design re-use)

Some synthesis tools support register retiming, so you could solve the
temporal problem by inserting otherwise empty pipeline stages before
and/or after the function call. I would suspect this will become an
increasingly important optimization capability in the near future.

Andy