Subject: Re: CP-003
From: Jim Lewis (jim@synthworks.com)
Date: Fri Jan 31 2003 - 09:21:57 PST
I have been using a pair of and functions from a
package I wrote for years now. I have also taught
students in all my courses to use these functions.
New users do not seem to have trouble picking up
on using the "and" function one way and the "+"
function the other.
New users also do not have an issue understanding
the use of (A'range => Asel). Unfortunately some
synthesis tools will not accept this alone and
require: std_logic_vector'(A'range => ASel)
Resize would be hugely confusing. We already use
a function named resize to change the size of
an array from one size to another.
The problem with the other solutions is typing.
We are getting blasted for the amount of
typing the language requires. Here is one place
the language does not require it.
What I am asking in this proposal (and the similar one
I requested of 1076.3 for "+") is that you remember an
additional set of properties:
For logic operators,
'1' becomes "111 ...1"
'0' becomes "000 ...0"
For math operators,
'1' becomes "000 ...1"
'0' becomes "000 ...0"
The expression rules of the language already asks us
to remember things like this. It is my thought that this
does not significantly increase those rules:
Expression Size of Y
---------- ---------------------------
Y <= A ; A'Length
Y <= A and B ; A'Length = B'Length
Y <= A > B ; Boolean
Y <= A + B ; Maximum (A'Length, B'Length)
Y <= A + 10 ; A'Length
Y <= A * B ; A'Length + B'Length
Yes, using arrays with bits does add some non-orthagonality
to the operator overloading, but this is engineering and
non-orthagonality is a normal part of life.
New operators (via 200x) could address some of your issues,
but I am not sure how this would make things more clear.
Cheers,
Jim
Jayaram Bhasker wrote:
> If a user does not realize/understand how to use (A'range => Asel),
> a suggestion would be to define a RESIZE function for std_logic. (or call
> it FANOUT - i prefer RESIZE since it matches what we have in
NUMERIC_STD).
>
> So I feel it is easier to write "A and RESIZE(Asel, A'Range)". By
default,
> it does 0 padding - a third optional argument can be used to override the
> pad bit. The expression now is clear as to its intent.
>
> - bhasker
>
> ------
> J. Bhasker, eSilicon Corp
> 1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
> jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
>
>
> -----Original Message-----
> From: Paul J. Menchini [mailto:mench@mench.com]
> Sent: Friday, January 31, 2003 10:40 AM
> To: Peter Ashenden
> Cc: vhdl-std-logic@eda.org
> Subject: Re: [Fwd: from [Jim Lewis <synthwrk@easystreet.com>]]
>
>
> Jim and all,
>
> I'm thinking about this issue, too. But, one thing struck me:
>
>
>>-----Forwarded Message-----
>
>
>>Date: Thu, 30 Jan 2003 18:57:53 -0800
>>From: Jim Lewis <synthwrk@easystreet.com>
>>To: Std_Logic 1164 <vhdl-std-logic@server.eda.org>
>>Cc: Jayaram Bhasker <jbhasker@ieee.org>
>>Subject: The logic behind CP-003
>>References: <200301310218.h0V2IcS2008944@server.eda.org>
>
>
>>>I vote to accept all except CP-003. I find this proposal
>>>non-intuitive. The more common interpretation is to treat '1' as
>>>"000...001", rather than "111....111". For example, "A and '1'"
>>>would mean "A and "000001"" which is same as "A + '1'" which means
>>>"A + "000001"". I therefore reject this proposal.
>>>
>>>- bhasker
>>
>
>>Bhasker,
>>I would like to convince you to vote otherwise on CP-003.
>
>
>>What you are saying makes sense for arithmetic operators. In fact,
>>we are proposing something similar to the above for +,- in 1076.3.
>>On the other hand, for controlling busses (logic),
>>applying the bit to the entire array makes sense.
>
>
>>I will show this with two applications:
>
>
>>Read-back logic for bus type logic.
>>===================================
>>Resources: ASel, BSel, ... outputs of a decoder
>>Busses to be controlled: A, B, ... all arrays.
>
>
>
>>The logic works something like this:
>>signal ASel, BSel : std_logic ;
>>signal Y, A, B : std_logic_vector(7 downto 0) ;
>
>
>>Y <= (A and ASel) or (B and BSel) ;
>
>
>>My challenge to you is, propose a hardware and code efficient
>>solution that effectively does this. One thing I have tried
>>that is not portable to synthesis tools is:
>
>
>>Y <= (A and (A'Range => ASel)) or (B and (B'Range => BSel)) ;
>
>
>>An alternate solution for this that does work requires intermediate
>>signals:
>>signal vASel, vBSel : std_logic_vector(A'range) ;
>
>
>>vASel <= (others => ASel) ;
>>vBSel <= (others => BSel) ;
>>Y <= (A and vASel) or (B and vBSel) ;
>
>
> No intermediate signals are required:
>
> Y <= (A and (A'range => ASel)) or (B and (B'range => BSel));
>
>
>>Conditional add/subtract:
>>===========================
>>signal SubSel : std_logic ; -- 1 = subtract, 0 = Add
>>signal Y, A, B : signed(7 downto 0) ;
>
>
>
>>-- subtraction via 1's complement + 1
>>Y <= A + (B xor SubSel) + SubSel ;
>
>
>>Interestingly enough this shows both the logic and the
>>arithmetic operation. For "xor SubSel", '1' becomes
>>"11111111" and '0' becomes "00000000". For "+ SubSel",
>>'1' becomes "00000001" and '0' becomes "00000000".
>
>
>>Note this is a very detailed implementation that I would
>>prefer not to use, however, sometimes to get good resource
>>sharing on synthesis tools this produces more effective
>>results than:
>
>
>>Y <= A + B when (SubSel = '1') else A - B ;
>
>
>
>>Without the new functions, intermediate signals would be required:
>>signal vSubSel : std_logic_vector(B'Range) ;
>
>
>>vSubSel <= (others => SubSel) ;
>
>
>>Y <= A + (B xor vSubSel) + SubSel ;
>
>
> Ditto:
>
> Y <= A + (B xor (B'range => SubSel)) + SubSel;
>
>
>>What I am trying to do with this proposal is to simplify some of the
>>tricks that are required to get a synthesis effective implementation
>>of the above code.
>
>
> Simplification is always good, as long as it doesn't lead to
> obsfucation.
>
>
>>These functions really help with the hardware implications.
>
>
> If so, then perhaps we can provide them with other names?
> Counter-intuitiveness (although somewhat in the mind of the intuiter)
> can lead to very hard to diagnose errors.
>
> Paul
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Fri Jan 31 2003 - 09:23:52 PST