From: Aaron J Eshelman <ajeshelman@raytheon.com>

Date: Sun Apr 25 2010 - 20:49:00 PDT

-----owner-vhdl-200x@eda.org wrote: -----

--

This message has been scanned for viruses and

dangerous content by**MailScanner**, and is

believed to be clean. Received on Sun Apr 25 20:49:24 2010

Date: Sun Apr 25 2010 - 20:49:00 PDT

A real matrix package that manipulates data in a matlab fashion would be very handy.

I'm not quite sure how you'd handle the signed/float methods yet. It seems that there would have to be some attribute constraints (or expand the language syntax a bit) applied to the operation to get something that is implementable at speed.

On the subject of real, has any idea been broached about constraining the representation of a real to something that is at least ieee single. Compile time generation of real constants using some of the math_real function calls that is consistent across simulation and synthesis tools would be a nice attribute.

To: Ernst Christen <christen.1858@verizon.net>

From: David Bishop <dbishop@eda.org>

Sent by: owner-vhdl-200x@eda.org

Date: 04/23/2010 04:01PM

cc: "vhdl-200x@eda.org" <vhdl-200x@eda.org>

Subject: Re: [vhdl-200x] [Fwd: VHDL vector/matrix package?]

Ernst Christen wrote:

> On 22 Apr 2010 Jonas Nilsson <Jonas.Nilsson@synopsys.com> wrote:

> >

> > I was thinking of a matrix package more in line with the

> MATH_COMPLEX/MATH_REAL

> > packages, that provides the functions but not the implementation. An

> RTL tool that

> > recognizes the operations and the following pipeline could make

> exactly the same

> > implementation as the "synthesis specific version", but the operators

> would be

> > useful in non-RTL code as well.

> >

> This is indeed what we were considering in 1076.1. The package would

> define the mathematical aspects of the operations, but no implementation.

>

> One thing we will consider is to define the vector/matrix package with

> a generic list that allows it to be instantiated for different types,

> for example the abstract data type real or a floating point type

> reflecting an implementation based on the float_generic_pkg. An

> instantiation using float_generic_pkg would then define an

> implementation for the data, but everything else would be left to the

> "synthesis specific version".

>

Why don't we start off with a "real_matrix" package, work out how we

want the algorithm to work there, then start playing with

unsigned/signed/ufixed/sfixed/float?

I already have a matrix multiply partially coded up. We actually

thought about doing matrix math long ago, but never actually did much

with it. Turns out that MTI takes the syntax fairly well.

--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

--

This message has been scanned for viruses and

dangerous content by

believed to be clean. Received on Sun Apr 25 20:49:24 2010

*
This archive was generated by hypermail 2.1.8
: Sun Apr 25 2010 - 20:49:49 PDT
*