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

Jonas Nilsson a écrit :
>> How would you handle synthesis of matrix multiplication, matrix
>> division, and matrix inversion? The timing of these operations in one
>> clock cycle would take a significant hit unless these operations where
>> pipelined. How would the designer constrain the synthesis of these
>> operations?
>>
>
> In RTL code, I would perform the operation, add the correct number of
> pipeline stages after the operation and ask the synthesis tool to retime
> the circuit.
>
> In high-level code, the tool would be constrained
> with parameters outside the VHDL code.
>

Attribute instances in expressions (a la Verilog) could make the
constraints expressed from the inside, on a per-operator granularity. To
do so, the expression grammar rules have to be extended first.

- Florent

Jonas Nilsson a écrit :
>> How would you handle synthesis of matrix multiplication, matrix
>> division, and matrix inversion? The timing of these operations in one
>> clock cycle would take a significant hit unless these operations where
>> pipelined. How would the designer constrain the synthesis of these
>> operations?
>>
>
> In RTL code, I would perform the operation, add the correct number of
> pipeline stages after the operation and ask the synthesis tool to retime
> the circuit.
>
> In high-level code, the tool would be constrained
> with parameters outside the VHDL code.
>
>
> I suppose that you suggest that the operators in this package would be procedure
> calls with more than the "normal" input operands? So you want to add at least
> a SIGNAL clock, a SIGNAL reset and a NATURAL to specify the required number of
> pipeline stages? That would be a very RTL-synthesis specific package, but it's
> of course an idea.
>
> 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.
>
>
> Regards,
> Jonas Nilsson
> Technical Staff
> Synplicity Business Group
> Synopsys, Inc.
> Kalkstensvägen 3
> SE-224 78 LUND
> SWEDEN
>
> Phone : +46-46-16 29 04
> Fax : +46-46-16 29 01
> E-mail: jonas@synopsys.com
> web : www.synopsys.com / www.synplicity.com
>
>
>
>
>> -----Original Message-----
>> From: Hoy, Scott - IS [mailto:Scott.Hoy@itt.com]
>> Sent: Thursday, April 22, 2010 4:05 PM
>> To: Jonas Nilsson; Ernst Christen; David Bishop; vhdl-200x@eda.org
>> Subject: RE: [vhdl-200x] [Fwd: VHDL vector/matrix package?]
>>
>> How would you handle synthesis of matrix multiplication, matrix
>> division, and matrix inversion? The timing of these operations in one
>> clock cycle would take a significant hit unless these operations where
>> pipelined. How would the designer constrain the synthesis of these
>> operations?
>>
>> On a side note, would it be beneficial for VHDL to adopt the .*, and ./
>> operators for denoting element-wise multiplication and division for
>> vectors and matrices?
>>
>> Scott D. Hoy
>> E-mail: scott.hoy@itt.com
>> Phone: 301-497-9900 Ext. 7162
>> Fax: 301-497-0207
>>
>> ITT-AES
>> 141 National Business Pkwy. Suite 200
>> Annapolis Junction, MD 20701
>> Phone: 301-497-9900 Fax: 301-497-0207
>>
>> -----Original Message-----
>> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
>> Of Jonas Nilsson
>> Sent: Thursday, April 22, 2010 8:25 AM
>> To: Ernst Christen; David Bishop; vhdl-200x@eda.org
>> Subject: RE: [vhdl-200x] [Fwd: VHDL vector/matrix package?]
>>
>> I disagree that it impacts synthesis.
>>
>> For RTL synthesis, the semantics are clear: Each in the matrix will be
>> synthesized
>> as normal signals (just like a normal array of arrays (of
>> arrays...aso)), and if a
>> matrix operation is encountered, it must be completed in a single clock
>> cycle.
>>
>> It's not different from using, say a division operation. It could also
>> be performed
>> using simpler operations over several cycles, but if used in RTL code,
>> it must be
>> fully executed in a single cycle, according to RTL semantics.
>>
>>
>> Higher level synthesis algorithms aren't impacted much either (at least
>> not
>> for compatibility reasons). Each matrix operation can be expanded into
>> its
>> partial operations, and those partial operations can be scheduled as
>> normal
>> scalar operations. How to represent and store object values,
>> intermediate values
>> and schedule the operations is up to the tool.
>> If anything, tools will be aided by a higher level description because
>> they
>> can use the higher-level operations to make some
>> simplifications/synthesis/scheduling
>> decisions earlier before expanding them into scalar operations and
>> making a
>> detailed schedule.
>>
>> Or is there any facet of this that I'm missing?
>>
>> I believe that your example use case is valid.
>> But it is in my opinion more related to "high level synthesis tools"
>> than to a language with built-in support for matrix/vector operations.
>>
>> Regards,
>> Jonas Nilsson
>> Technical Staff
>> Synplicity Business Group
>> Synopsys, Inc.
>> Kalkstensvägen 3
>> SE-224 78 LUND
>> SWEDEN
>>
>> Phone : +46-46-16 29 04
>> Fax : +46-46-16 29 01
>> E-mail: jonas@synopsys.com
>> web : www.synopsys.com / www.synplicity.com
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On
>>>
>> Behalf
>>
>>> Of Ernst Christen
>>> Sent: Tuesday, April 20, 2010 6:41 PM
>>> To: David Bishop; vhdl-200x@eda.org
>>> Subject: Re: [vhdl-200x] [Fwd: VHDL vector/matrix package?]
>>>
>>> Yes, I can see that for VHDL synthesis compatibility will be an issue.
>>> This is something we haven't seen with 1076.1 yet as there is no AMS
>>> synthesis. I think this raises two questions:
>>>
>>> Would a vector/matrix capability be useful without considerations for
>>> synthesis compatibility, for example for behavioral models used during
>>> verification?
>>> What additional requirements would be imposed to make vector/matrix
>>> operations synthesis compatible? Specifically, what scope are we
>>>
>> talking
>>
>>> about. For example, is something like synthesizing a signal processor
>>> given an algorithm a valid use case?
>>>
>>> Ernst
>>> --
>>> Ernst Christen, christen.1858@verizon.net on 4/20/2010
>>>
>>>
>>>> On 4/15/2010 9:26 AM, Jim Lewis wrote:
>>>>
>>>>
>>>>> Has anything like this been considered for 1076, or do you know of
>>>>>
>>> an
>>>
>>>>> implementation of a proprietary package for this purpose? We have
>>>>>
>>> not
>>>
>>>>> gone far with it yet, we are still discussing requirements and
>>>>>
>>> scope.
>>>
>>>>> Any information you have will be helpful for out planning. I am
>>>>>
>> also
>>
>>>>> planning to consult with vhdl-200x to get feedback before we move
>>>>> beyond
>>>>> requirements.
>>>>>
>>>> I started looking into this about 2 years ago. Lately I've been
>>>>
>> doing
>>
>>> a
>>>
>>>> good deal of work with Matlab, and seeing how easy it is to
>>>>
>> manipulate
>>
>>> a
>>>
>>>> matrix in that language. I'd like to see that sort of ability in
>>>>
>>> VHDL.
>>>
>>>> The big issue as I see it is synthesis compatibility. You pretty
>>>>
>> much
>>
>>>> can't do this without the ability to infer a memory element. You
>>>>
>> also
>>
>>>> need some sort of trade off between different types of memories.
>>>> How would you declare a matrix of X dimensions generically?
>>>>
>>> --
>>> 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 MailScanner, and is
>> believed to be clean.
>>
>>
>>
>> This e-mail and any files transmitted with it may be proprietary and are
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this e-mail in error please notify the
>> sender.
>> Please note that any views or opinions presented in this e-mail are
>> solely those of the author and do not necessarily represent those of ITT
>> Corporation. The recipient should check this e-mail and any attachments
>> for the presence of viruses. ITT accepts no liability for any damage
>> caused by any virus transmitted by this e-mail.
>>
>
>

-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.