Just wondering if this is something Ive done wrong, or if its a
modelsim bug.

Here is the problem code:

process
    variable uf : ufixed(7 downto   -7) := to_ufixed( 1, 7, -7);
    variable sf : sfixed(8 downto   -7) := to_sfixed(-2, 8, -7);
    variable op : sfixed(17 downto -14);
  begin

    op := sf * sfixed('0' & uf);
  	wait;
  end process;

and here is the error:

# ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a
literal used?
#    Time: 0 ps  Iteration: 0  Instance: /play_tb
# ** Warning: (vsim-WLF-5000) WLF file currently in use: vsim.wlf
#           File in use by: 113007238  Hostname: IND-JJYK03JG1
ProcessID: 9164
#           Attempting to use alternate WLF file "./wlftrh7wd7".
# ** Warning: (vsim-WLF-5001) Could not open WLF file: vsim.wlf
#           Using alternate file: ./wlftrh7wd7
# ** Fatal: (vsim-3420) Array lengths do not match. Left is 30 (15
downto -14). Right is 0 (0 downto 1 (null array)).
#    Time: 0 ps  Iteration: 0  Process: /play_tb/line__21 File:
play_tb.vhd
# Fatal error in Process line__21 at play_tb.vhd line 26


If I take the type conversion out of the assignment line and have a
temporary variable for just the type conversion, there is no error:

temp := sfixed('0' & uf);
    op := sf * temp;

Might be a bug, seems fine with default optimisation but if enable full 
visibility I get the same error as you (I also tried -novopt)

D:\Modelsim>vsim -c -quiet test_tb
Reading D:/modeltech_SE_6.6b/tcl/vsim/pref.tcl

# 6.6b

# vsim -c -quiet test_tb
# //  ModelSim SE 6.6b May 21 2010
# //
# //  Copyright 1991-2010 Mentor Graphics Corporation
# //              All Rights Reserved.
# //
# //  THIS WORK CONTAINS TRADE SECRET AND
# //  PROPRIETARY INFORMATION WHICH IS THE PROPERTY
# //  OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
# //  AND IS SUBJECT TO LICENSE TERMS.
# //
VSIM 1> vsim -quiet test_tb
# vsim -quiet test_tb
VSIM 2> run 1 us
VSIM 3> vsim -quiet -voptargs=+acc test_tb
# vsim -voptargs=+acc -quiet test_tb
VSIM 4> run 1 us
# ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a literal used?
#    Time: 0 ns  Iteration: 0  Instance: /test_tb
# ** Fatal: (vsim-3420) Array lengths do not match. Left is 32 (17 downto -14). 
Right is 0 (0 downto 1 (null array)).
#    Time: 0 ns  Iteration: 0  Process: /test_tb/line__17 File: test_ufix.vhd
# Fatal error in Process line__17 at test_ufix.vhd line 22
VSIM 5>

Pass it on to Mentor, if you are lucky it might still make 6.6c :-)

Hans.
www.ht-lab.com



"Tricky" <trickyhead@gmail.com> wrote in message 
news:873cd548-dd7f-4188-b9f0-f33a900c2ae0@m1g2000yqo.googlegroups.com...
> Just wondering if this is something Ive done wrong, or if its a
> modelsim bug.
>
> Here is the problem code:
>
> process
>    variable uf : ufixed(7 downto   -7) := to_ufixed( 1, 7, -7);
>    variable sf : sfixed(8 downto   -7) := to_sfixed(-2, 8, -7);
>    variable op : sfixed(17 downto -14);
>  begin
>
>    op := sf * sfixed('0' & uf);
>  wait;
>  end process;
>
> and here is the error:
>
> # ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a
> literal used?
> #    Time: 0 ps  Iteration: 0  Instance: /play_tb
> # ** Warning: (vsim-WLF-5000) WLF file currently in use: vsim.wlf
> #           File in use by: 113007238  Hostname: IND-JJYK03JG1
> ProcessID: 9164
> #           Attempting to use alternate WLF file "./wlftrh7wd7".
> # ** Warning: (vsim-WLF-5001) Could not open WLF file: vsim.wlf
> #           Using alternate file: ./wlftrh7wd7
> # ** Fatal: (vsim-3420) Array lengths do not match. Left is 30 (15
> downto -14). Right is 0 (0 downto 1 (null array)).
> #    Time: 0 ps  Iteration: 0  Process: /play_tb/line__21 File:
> play_tb.vhd
> # Fatal error in Process line__21 at play_tb.vhd line 26
>
>
> If I take the type conversion out of the assignment line and have a
> temporary variable for just the type conversion, there is no error:
>
> temp := sfixed('0' & uf);
>    op := sf * temp;
>
> 

On 27 Aug, 16:18, "HT-Lab" <han...@ht-lab.com> wrote:
> Might be a bug, seems fine with default optimisation but if enable full
> visibility I get the same error as you (I also tried -novopt)
>
> D:\Modelsim>vsim -c -quiet test_tb
> Reading D:/modeltech_SE_6.6b/tcl/vsim/pref.tcl
>
> # 6.6b
>
> # vsim -c -quiet test_tb
> # // =A0ModelSim SE 6.6b May 21 2010
> # //
> # // =A0Copyright 1991-2010 Mentor Graphics Corporation
> # // =A0 =A0 =A0 =A0 =A0 =A0 =A0All Rights Reserved.
> # //
> # // =A0THIS WORK CONTAINS TRADE SECRET AND
> # // =A0PROPRIETARY INFORMATION WHICH IS THE PROPERTY
> # // =A0OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
> # // =A0AND IS SUBJECT TO LICENSE TERMS.
> # //
> VSIM 1> vsim -quiet test_tb
> # vsim -quiet test_tb
> VSIM 2> run 1 us
> VSIM 3> vsim -quiet -voptargs=3D+acc test_tb
> # vsim -voptargs=3D+acc -quiet test_tb
> VSIM 4> run 1 us
> # ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a litera=
l used?
> # =A0 =A0Time: 0 ns =A0Iteration: 0 =A0Instance: /test_tb
> # ** Fatal: (vsim-3420) Array lengths do not match. Left is 32 (17 downto=
 -14).
> Right is 0 (0 downto 1 (null array)).
> # =A0 =A0Time: 0 ns =A0Iteration: 0 =A0Process: /test_tb/line__17 File: t=
est_ufix.vhd
> # Fatal error in Process line__17 at test_ufix.vhd line 22
> VSIM 5>
>
> Pass it on to Mentor, if you are lucky it might still make 6.6c :-)
>
> Hans.www.ht-lab.com
>
> "Tricky" <trickyh...@gmail.com> wrote in message
>
> news:873cd548-dd7f-4188-b9f0-f33a900c2ae0@m1g2000yqo.googlegroups.com...
>
> > Just wondering if this is something Ive done wrong, or if its a
> > modelsim bug.
>
> > Here is the problem code:
>
> > process
> > =A0 =A0variable uf : ufixed(7 downto =A0 -7) :=3D to_ufixed( 1, 7, -7);
> > =A0 =A0variable sf : sfixed(8 downto =A0 -7) :=3D to_sfixed(-2, 8, -7);
> > =A0 =A0variable op : sfixed(17 downto -14);
> > =A0begin
>
> > =A0 =A0op :=3D sf * sfixed('0' & uf);
> > =A0wait;
> > =A0end process;
>
> > and here is the error:
>
> > # ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a
> > literal used?
> > # =A0 =A0Time: 0 ps =A0Iteration: 0 =A0Instance: /play_tb
> > # ** Warning: (vsim-WLF-5000) WLF file currently in use: vsim.wlf
> > # =A0 =A0 =A0 =A0 =A0 File in use by: 113007238 =A0Hostname: IND-JJYK03=
JG1
> > ProcessID: 9164
> > # =A0 =A0 =A0 =A0 =A0 Attempting to use alternate WLF file "./wlftrh7wd=
7".
> > # ** Warning: (vsim-WLF-5001) Could not open WLF file: vsim.wlf
> > # =A0 =A0 =A0 =A0 =A0 Using alternate file: ./wlftrh7wd7
> > # ** Fatal: (vsim-3420) Array lengths do not match. Left is 30 (15
> > downto -14). Right is 0 (0 downto 1 (null array)).
> > # =A0 =A0Time: 0 ps =A0Iteration: 0 =A0Process: /play_tb/line__21 File:
> > play_tb.vhd
> > # Fatal error in Process line__21 at play_tb.vhd line 26
>
> > If I take the type conversion out of the assignment line and have a
> > temporary variable for just the type conversion, there is no error:
>
> > temp :=3D sfixed('0' & uf);
> > =A0 =A0op :=3D sf * temp;
>
>

Its a confirmed bug - Defect report raised.

That makes 3 outstanding for me!

Tricky wrote:

> Its a confirmed bug - Defect report raised.
> 
> That makes 3 outstanding for me!

And sadly 13 for me...

-- 
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

On 27 Aug, 17:12, Tricky <trickyh...@gmail.com> wrote:
> On 27 Aug, 16:18, "HT-Lab" <han...@ht-lab.com> wrote:
>
>
>
> > Might be a bug, seems fine with default optimisation but if enable full
> > visibility I get the same error as you (I also tried -novopt)
>
> > D:\Modelsim>vsim -c -quiet test_tb
> > Reading D:/modeltech_SE_6.6b/tcl/vsim/pref.tcl
>
> > # 6.6b
>
> > # vsim -c -quiet test_tb
> > # // =A0ModelSim SE 6.6b May 21 2010
> > # //
> > # // =A0Copyright 1991-2010 Mentor Graphics Corporation
> > # // =A0 =A0 =A0 =A0 =A0 =A0 =A0All Rights Reserved.
> > # //
> > # // =A0THIS WORK CONTAINS TRADE SECRET AND
> > # // =A0PROPRIETARY INFORMATION WHICH IS THE PROPERTY
> > # // =A0OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
> > # // =A0AND IS SUBJECT TO LICENSE TERMS.
> > # //
> > VSIM 1> vsim -quiet test_tb
> > # vsim -quiet test_tb
> > VSIM 2> run 1 us
> > VSIM 3> vsim -quiet -voptargs=3D+acc test_tb
> > # vsim -voptargs=3D+acc -quiet test_tb
> > VSIM 4> run 1 us
> > # ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a lite=
ral used?
> > # =A0 =A0Time: 0 ns =A0Iteration: 0 =A0Instance: /test_tb
> > # ** Fatal: (vsim-3420) Array lengths do not match. Left is 32 (17 down=
to -14).
> > Right is 0 (0 downto 1 (null array)).
> > # =A0 =A0Time: 0 ns =A0Iteration: 0 =A0Process: /test_tb/line__17 File:=
 test_ufix.vhd
> > # Fatal error in Process line__17 at test_ufix.vhd line 22
> > VSIM 5>
>
> > Pass it on to Mentor, if you are lucky it might still make 6.6c :-)
>
> > Hans.www.ht-lab.com
>
> > "Tricky" <trickyh...@gmail.com> wrote in message
>
> >news:873cd548-dd7f-4188-b9f0-f33a900c2ae0@m1g2000yqo.googlegroups.com...
>
> > > Just wondering if this is something Ive done wrong, or if its a
> > > modelsim bug.
>
> > > Here is the problem code:
>
> > > process
> > > =A0 =A0variable uf : ufixed(7 downto =A0 -7) :=3D to_ufixed( 1, 7, -7=
);
> > > =A0 =A0variable sf : sfixed(8 downto =A0 -7) :=3D to_sfixed(-2, 8, -7=
);
> > > =A0 =A0variable op : sfixed(17 downto -14);
> > > =A0begin
>
> > > =A0 =A0op :=3D sf * sfixed('0' & uf);
> > > =A0wait;
> > > =A0end process;
>
> > > and here is the error:
>
> > > # ** Error: :floatfixlib:fixed_pkg: Unbounded number passed, was a
> > > literal used?
> > > # =A0 =A0Time: 0 ps =A0Iteration: 0 =A0Instance: /play_tb
> > > # ** Warning: (vsim-WLF-5000) WLF file currently in use: vsim.wlf
> > > # =A0 =A0 =A0 =A0 =A0 File in use by: 113007238 =A0Hostname: IND-JJYK=
03JG1
> > > ProcessID: 9164
> > > # =A0 =A0 =A0 =A0 =A0 Attempting to use alternate WLF file "./wlftrh7=
wd7".
> > > # ** Warning: (vsim-WLF-5001) Could not open WLF file: vsim.wlf
> > > # =A0 =A0 =A0 =A0 =A0 Using alternate file: ./wlftrh7wd7
> > > # ** Fatal: (vsim-3420) Array lengths do not match. Left is 30 (15
> > > downto -14). Right is 0 (0 downto 1 (null array)).
> > > # =A0 =A0Time: 0 ps =A0Iteration: 0 =A0Process: /play_tb/line__21 Fil=
e:
> > > play_tb.vhd
> > > # Fatal error in Process line__21 at play_tb.vhd line 26
>
> > > If I take the type conversion out of the assignment line and have a
> > > temporary variable for just the type conversion, there is no error:
>
> > > temp :=3D sfixed('0' & uf);
> > > =A0 =A0op :=3D sf * temp;
>
> Its a confirmed bug - Defect report raised.
>
> That makes 3 outstanding for me!

Apparently it might not be a modelsim bug. Here is their latest
response:

I had a few suspicions about this error, so first wanted to check with
R&D before raising any DR. Here is what they said about the error:

>>>>
This is definitely not a ModelSim implementation issue. The fixed
package uses array indexes in a critical way.
uf has indexes 7 downto -7.
When you concatenate a '0' to the left of this value you get the
correct bit pattern, but the wrong index values. specifically, you do
not get 8 downto -7.
The workaround is OK because it takes the desired bit pattern, and
assigns it to a variable which has the correct index values.
<<<<

BTW, I should add this is a shortcoming in the fixed package.

On Tue, 31 Aug 2010 00:17:24 -0700 (PDT), Tricky wrote:

[from Mentor]
> The fixed package uses array indexes in a critical way.
>uf has indexes 7 downto -7.
>When you concatenate a '0' to the left of this value you get the
>correct bit pattern, but the wrong index values. specifically, you do
>not get 8 downto -7.
>The workaround is OK because it takes the desired bit pattern, and
>assigns it to a variable which has the correct index values.

[Tricky]
>BTW, I should add this is a shortcoming in the fixed package.

I agree; I was under the impression that all the FP operators
complain if given arrays with the wrong range direction.

You could work around it without the temporary
variable, by using a subtype to do the conversion:

  subtype sfix9f7 is sfixed(8 downto -7);
  ..
  op := sf * sfix9f7('0' & uf);

Now the constrained subtype sfix9f7 coerces the result 
to have the right array range.
-- 
Jonathan Bromley

On Aug 31, 2:45=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Tue, 31 Aug 2010 00:17:24 -0700 (PDT), Tricky wrote:
> >BTW, I should add this is a shortcoming in the fixed package.
>
> I agree; I was under the impression that all the FP operators
> complain if given arrays with the wrong range direction.

Am I missing something?

op :=3D sf * to_sfixed(uf);

to_sfixed() automatically pads the ufixed with the sign bit for you,
and it is much more readable.

Before assuming the package has a shortcoming, make sure you know (and
use) what's already available in the package. The concatenation result
range issue is with vhdl, not fixed point. Avoid concatenating fixed
point values.

Andy

On Tue, 31 Aug 2010 08:28:02 -0700 (PDT), Andy wrote:

>On Aug 31, 2:45�am, Jonathan Bromley wrote:
>> I was under the impression that all the FP operators
>> complain if given arrays with the wrong range direction.

>Am I missing something?
>   op := sf * to_sfixed(uf);
>to_sfixed() automatically pads the ufixed with the sign bit for you,
>and it is much more readable

Whoops, that'll teach me not to discuss things I don't use
actively. Didn't know that, thanks Andy.  Yes, of course that's
the right way to get that effect.

>Before assuming the package has a shortcoming, make sure you know (and
>use) what's already available in the package. The concatenation result
>range issue is with vhdl, not fixed point.

That's a bit harsh.  Since the FP package absolutely requires
that vector ranges all be "downto", and the language cannot
enforce that, it's kinda disappointing that the package 
doesn't assert the check whenever it gets the chance.  The
concat rules are indeed weird, but it's hard to see what the
language could have done to make them better in ALL useful
cases.

> Avoid concatenating fixed point values.

Probably very good advice, but not as important as
  ** avoid using VHDL assignment to copy **
  ** one fixed-point vector into another **
violation of which simply gives wrong answers, with no 
possibility whatsoever of any checking.

Thanks again
-- 
Jonathan Bromley

Just like other operators, the language could have chosen a specific
range result based on the operands (like extending the range of the
largest operand, or if equal, picking L or R consistently). Instead,
it defaults to something not particularly useful for any application.
I suspect the original authors did not expect that indices would be
used for specific purposes as in the fixed and floating point
languages.

The fixed point user guide says:
'A negative or =93to=94 index is flagged as an error by the fixed-point
routines. Thus, if you define a number as =93ufixed (1 to 5)=94 the
routines will automatically error out.'

Apparently that did not make it into the package?

BTW, surely this was not intended to prevent usage of e.g. ufixed(-4
downto -7)?

The only way to fix the assignment issue is to add overloaded
assignment operators to the language, which IMHO should have been
added a long time ago. In the meantime, it would be beneficial to get
into the habit of always using resize() prior to assignment.

op :=3D resize(sf * to_sfixed(uf), op);

Since op might be the right size, while not of the right "shape".

Andy

On Tue, 31 Aug 2010 10:49:16 -0700 (PDT), Andy wrote:

>The fixed point user guide says:
>'A negative or �to� index is flagged as an error by the fixed-point
>routines. Thus, if you define a number as �ufixed (1 to 5)� the
>routines will automatically error out.'

Yes, I thought I had a folk-memory of something like that.

>Apparently that did not make it into the package?

Maybe it's been taken out of some versions for performance
reasons?  The problem, of course, is that an assertion
on every function call is likely to perform very many
redundant checks.  On the other hand it's a pretty cheap
check, so I would still prefer to see it in place.

>BTW, surely this was not intended to prevent usage of 
>e.g. ufixed(-4 downto -7)?

I guess that's a documentation slip-up.

>The only way to fix the assignment issue is to add overloaded
>assignment operators to the language, which IMHO should have been
>added a long time ago.

Couldn't agree with you more; I've even put in a request
for exactly that.

>In the meantime, it would be beneficial to get
>into the habit of always using resize() prior to assignment.
>   op := resize(sf * to_sfixed(uf), op);

That was a brilliant trick of Dave Bishop's, to add the
"shape-only" argument to resize().  Much nicer to use
than the copy procedures that I created when I did a 
FP package...

  copyV(variable_target, source);
  copyS(signal_target, source);

Apart from the syntactic clumsiness, their being
procedures precludes their use in a function.  (Cue 
complaint #N+1 about VHDL: we need void-functions with
output arguments, like procedures but not time-consuming).

Ah me.  You got me all wound up again.... sorry!
-- 
Jonathan Bromley