Subject: [Fwd: Re: 1076.3 additions]
From: Rob Anderson (rob@reawebtech.com)
Date: Mon Sep 30 2002 - 15:05:00 PDT
-------- Original Message --------
From: - Mon Sep 30 15:04:12 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Message-ID: <3D98CA5C.7020200@reawebtech.com>
Date: Mon, 30 Sep 2002 15:04:12 -0700
From: Rob Anderson <rob@reawebtech.com>
Reply-To: rob@reawebtech.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1)
Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jim Lewis <jim@synthworks.com>
Subject: Re: 1076.3 additions
References: <3D937142.60406@reawebtech.com>
<3D98C3F0.70B2E3D6@SynthWorks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Normally there is add, addc, sub, subc.
It is assumed there is a carry in and carry out for addc,
but just a carry out for add.
Co tells you about the overflow/underflow status for signed. I
don't think we want to spec. more flags because it starts to
dictate the implementation.
I agree with the separate package, and if we are putting
regs, muxes, etc. in, let us call it something else like alu_std.pkg
and alu_bit.pkg.
--Rob
Jim Lewis wrote:
>
> Rob Anderson wrote:
>
>>- snip -
>>
>
>>Another idea from vhdlsynth (Vallenga) was procedures so that the
>>carry/borrow bit could be expressed more naturally in the code,
>>E.G.
>>
>>procedure addc(a,b: in signed; cin: in std_logic; y: out signed;
>> cf: out std_logic);
>>
>>
>
> I like it. I could see a number of subprograms like these.
> One in particular is AddSub. Is AddC add with carry in and carry
> out? Would one general AddC be good or AddCi, AddCo, and AddCiCo be
> more appropriate? I am thinking in general of how can we get both a
> function and a procedure implementation of these (function would have
> the Co in the upper bit of the result). In addition, does AddCiCo for
> signed reqiure an overflow bit?
>
> Would these go in numeric_std or a separate package?
> I would vote for a separate package. Additional possibilities
> I have in mind are Mux2, Mux4, and a number of flavors of registers.
> While some of these may be trivial, I think they may give simulation
> vendors the opportunity to optimize common hardware structures.
> I know at one point I saw a package from EDIF LPM (Library of
> parameterized Modules) that had something like this. I ignored them
> as they used string generics and at the time were not useful in
> all synthesis tools.
>
> If a register package were done separately, it could be possible
> to switch between asynchronous reset registers (preferred in FPGAs) to
> synchronous reset registers (preferred in ASICs) simpily by switching
> packages.
>
> Cheers,
> Jim
>
This archive was generated by hypermail 2b28 : Mon Sep 30 2002 - 15:04:16 PDT