David, I agree whole-heartedly with the "lossless" theory of operations (except for division). I sometimes use ufixed instead of unsigned just because of the lossless arithmetic* when integers won't handle the range. While in vhdl-2008 I can declare constants using the initialization expression to set the range, I cannot do that with variable/signal declarations. You can however declare "sizer" constants this way, and then use their ranges to declare the variables/signals. Just a little more verbose... I don't really think there is a better way to do it with functions than what you did, and the packages as a whole are fundamental game-changers for VHDL synthesis. Not even SV can do that! *I only wish there was a seamless way to make ufixed subtraction expand to sfixed, and handle mixed sfixed/ufixed arithmetic in a clean yet reasonable way. I often use the (natural - 1 < 0) trick to catch the carry/borrow on down-counters. Andy D Jones Electrical Engineering Lockheed Martin Missiles and Fire Control Dallas TX -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of David Bishop Sent: Wednesday, April 24, 2013 4:00 PM To: vhdl-200x@eda.org Subject: Re: EXTERNAL: Re: [vhdl-200x] Sizing of variables and signals from initial values On 04/24/2013 03:02 PM, Jones, Andy D wrote: > Formatting error... example should be: > > Variable a, b : ufixed(arg'range) := (others => '0'); -- 0.0 > > Variable sum : ufixed := a + b; -- also 0.0, but "bigger" > > Variable product : ufixed := a * b; -- still 0.0, but even "bigger" > Cleaver. This will work to bound the types. I admit the helper scripts here are a bit verbose, but I could not think of a better way to do it. The idea here is that none of the operations do any rounding, they just let the number grow. The way I fix this issue is like this: variable a, b : ufixed (arg'range); variable result : ufixed (arg'range); result := resize ((a + b) * a, result'high, result'low); -- 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.Received on Wed Apr 24 16:47:29 2013
This archive was generated by hypermail 2.1.8 : Wed Apr 24 2013 - 16:48:09 PDT