Where did the Null array come from?

[Tricky]

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;

 

[HT-Lab]

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]

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

Its a confirmed bug - Defect report raised.

That makes 3 outstanding for me!

 

[Paul Uiterlinden]

Its a confirmed bug - Defect report raised.

That makes 3 outstanding for me!

And sadly 13 for me...

 

[Tricky]

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.

 

[Jonathan Bromley]

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.

 

[Andy]

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 := 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

 

[Jonathan Bromley]

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

 

[Andy]

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 “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.'

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 := resize(sf * to_sfixed(uf), op);

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

Andy

 

[Jonathan Bromley]

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!