Xilinx "something's wrong" error

S

Sergey Katsev

Guest
Hi All,

I'm trying to synthesize a pretty complex system which simulates fine in
ModelSim (I know that this doesn't mean it's synthesizable, but I'm
trying to get to that point).

Part-way through the synthesis (on the second component that it actually
tries to do HDL synthesis on, after it does all the generics
instantiation and all that), ISE gives me it's famous "something went
wrong... contact support" error message.

Is there any indication about *where* it went wrong, so I can at least
try to re-write that code? What's the best way of trying to tackle this
issue?

Thanks,

Sergey
 
Sergey Katsev wrote:

Is there any indication about *where* it went wrong, so I can at least
try to re-write that code? What's the best way of trying to tackle this
issue?
Click to expand...
With vhdl simulation.
Maybe you gave synthesis an impossible task
that it hasn't seen before.
Start with a working example or
design the uut using a synchronous template
that has a chance to work.
Write and run a testbench that shows the logic is right.
Run synthesis and view the RTL schematic.


http://home.comcast.net/~mike_treseler/
 
Thanks for your response Mike.

As far as I know, the code is synchronous and should be synthesizable.
It's several components comprised of generically generated systolic
arrays, but the array elements are just arithmetic operations.

The element that it "dies" on should just be two flip-flops:

entity A1circ is
port( clk : in std_logic := '0';
X : in sfixed_c := (others=> '0'); -- input
flag_in : in std_logic := '0';
Y : out sfixed_c := (others=> '0'); -- output
flag_out : out std_logic := '0'
);
end A1circ;

architecture behav of A1circ is

begin
process(clk)
begin
if rising_edge(clk) then
Y <= X;
flag_out <= flag_in;
end if;
end process;
end behav;

Is there anything wrong with that piece of code?... or does the fact
that the fatal error occurs when synthesizing this unit doesn't
necessarily imply that this is where the problem resides?

Thanks again...

Here's the XST output (the last few lines):

=========================================================================
* HDL Synthesis *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <validator>.
Related source file is
"C:/thesis/SDRE/VHDL/FINAL/final/validator.vhdl".
Unit <validator> synthesized.


Synthesizing Unit <A1circ>.
Related source file is "C:/thesis/SDRE/VHDL/FINAL/final/A1circ.vhdl".
FATAL_ERROR:Xst:portability/export/Port_Main.h:127:1.16 - This
application has discovered an exceptional condition from which it cannot
recover. Process will terminate. To resolve this error, please consult
the Answers Database and other online resources at
http://support.xilinx.com. If you need further assistance, please open a
Webcase by clicking on the "WebCase" link at http://support.xilinx.com

Process "Synthesize" failed



Mike Treseler wrote:
Sergey Katsev wrote:

Is there any indication about *where* it went wrong, so I can at least
try to re-write that code? What's the best way of trying to tackle
this issue?

With vhdl simulation.
Maybe you gave synthesis an impossible task
that it hasn't seen before.
Start with a working example or
design the uut using a synchronous template
that has a chance to work.
Write and run a testbench that shows the logic is right.
Run synthesis and view the RTL schematic.


http://home.comcast.net/~mike_treseler/
Click to expand...
 
Sergey Katsev wrote:
Thanks for your response Mike.

The element that it "dies" on should just be two flip-flops:

entity A1circ is
port( clk : in std_logic := '0';
X : in sfixed_c := (others=> '0'); -- input
Click to expand...
I expect that sfixed_c type requires
a more specific assignment than (others=> '0');
Run vcom on the source for a better error description.

-- Mike Treseler
 
Ben Jones wrote:
"Sergey Katsev" <sergey.katsev@coyotepoint.com> wrote in message
news:NcudnTpr-bbq6NrYnZ2dnUVZ_rudnZ2d@neonova.net...
Thanks for your response Ben...

I'm using ISE 8.2i

I posted the piece that I think it's getting stuck on in a previous
message... but (unless I'm missing something obvious), I don't really see
how it could get stuck on that code...

Yes, it does look like the simplest of the simple...

Is sfixed_c just an explicitly ranged subtype of std_logic_vector?

-Ben-
Click to expand...
Does ISE accept negative indices on SLV? It seems like I've heard it
has problems with the ieee candidate fixed point package for that
reason.

Andy
 
"Sergey Katsev" <sergey.katsev@coyotepoint.com> wrote in message
news:p8ydnW6apIYP-9rYnZ2dnUVZ_r2dnZ2d@neonova.net...
Hi All,

I'm trying to synthesize a pretty complex system which simulates fine in
ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
to get to that point).

Part-way through the synthesis (on the second component that it actually
tries to do HDL synthesis on, after it does all the generics instantiation
and all that), ISE gives me it's famous "something went wrong... contact
support" error message.
Click to expand...
We all hate this error.

Could you specify what version of ISE you are using

Is there any indication about *where* it went wrong, so I can at least try
to re-write that code? What's the best way of trying to tackle this
issue?
Click to expand...
A few ideas:

Try synthesizing the subcomponent in isolation (rather than in the context
of the larger system) and see if the issue still occurs.

Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
constants using complicated functions, using records, arrays of records,
records of records, anything that's not straight out of a textbook).

Try the "binary search" method - comment out half your file and re-run
synthesis; if it starts working then the error is in the commented-out half;
iterate until you've found the line it doesn't like.

If you can post some of your code at any stage of the debugging process, you
might find that someone in this newsgroup can tell you exactly what the
problem is straight away. These sorts of banging-head-against-the-wall
issues tend to stick in the mind somewhat... :)

Cheers,

-Ben-
 
Thanks for your response Ben...

I'm using ISE 8.2i

I posted the piece that I think it's getting stuck on in a previous
message... but (unless I'm missing something obvious), I don't really
see how it could get stuck on that code...

-- Sergey

Ben Jones wrote:
"Sergey Katsev" <sergey.katsev@coyotepoint.com> wrote in message
news:p8ydnW6apIYP-9rYnZ2dnUVZ_r2dnZ2d@neonova.net...
Hi All,

I'm trying to synthesize a pretty complex system which simulates fine in
ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
to get to that point).

Part-way through the synthesis (on the second component that it actually
tries to do HDL synthesis on, after it does all the generics instantiation
and all that), ISE gives me it's famous "something went wrong... contact
support" error message.

We all hate this error.

Could you specify what version of ISE you are using

Is there any indication about *where* it went wrong, so I can at least try
to re-write that code? What's the best way of trying to tackle this
issue?

A few ideas:

Try synthesizing the subcomponent in isolation (rather than in the context
of the larger system) and see if the issue still occurs.

Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
constants using complicated functions, using records, arrays of records,
records of records, anything that's not straight out of a textbook).

Try the "binary search" method - comment out half your file and re-run
synthesis; if it starts working then the error is in the commented-out half;
iterate until you've found the line it doesn't like.

If you can post some of your code at any stage of the debugging process, you
might find that someone in this newsgroup can tell you exactly what the
problem is straight away. These sorts of banging-head-against-the-wall
issues tend to stick in the mind somewhat... :)

Cheers,

-Ben-
Click to expand...
 
"Sergey Katsev" <sergey.katsev@coyotepoint.com> wrote in message
news:NcudnTpr-bbq6NrYnZ2dnUVZ_rudnZ2d@neonova.net...
Thanks for your response Ben...

I'm using ISE 8.2i

I posted the piece that I think it's getting stuck on in a previous
message... but (unless I'm missing something obvious), I don't really see
how it could get stuck on that code...
Click to expand...
Yes, it does look like the simplest of the simple...

Is sfixed_c just an explicitly ranged subtype of std_logic_vector?

-Ben-
 
Ben Jones wrote:
"Sergey Katsev" <sergey.katsev@coyotepoint.com> wrote in message
news:NcudnTpr-bbq6NrYnZ2dnUVZ_rudnZ2d@neonova.net...
Thanks for your response Ben...

I'm using ISE 8.2i

I posted the piece that I think it's getting stuck on in a previous
message... but (unless I'm missing something obvious), I don't really see
how it could get stuck on that code...

Yes, it does look like the simplest of the simple...

Is sfixed_c just an explicitly ranged subtype of std_logic_vector?

-Ben-


The sfixed_c type is from David Bishop's fixed point library... and that
Click to expand...
synthesizes fine in a smaller test case I have.

-- Sergey
 
Hmm...

sfixed_c is just a subtype defined to sfixed(32 downto -32).

However, when I try to do
in1, in2 : in sfixed(32 downto -32) := (others=>'0')

ISE tells me that "type of in1 is incompatible with type of aggregate".
Could it be that when I "mask" the type by using a subtype, ISE gets
confused?

(I can't actually test on the other code right now since I dont have it
with me)

How would I assign the inputs more explicitly? Or, do you mean just do
it inside of a process?

Thanks,

Sergey

Mike Treseler wrote:
Sergey Katsev wrote:
Thanks for your response Mike.

The element that it "dies" on should just be two flip-flops:

entity A1circ is
port( clk : in std_logic := '0';
X : in sfixed_c := (others=> '0'); -- input

I expect that sfixed_c type requires
a more specific assignment than (others=> '0');
Run vcom on the source for a better error description.

-- Mike Treseler
Click to expand...
 
Sergey,
Perhaps you could consider not initializing all of the
inputs and outputs.

If you are using this to imply
some form of power-on reset, keep in mind that this is
a Xilinx specific feature and will not port to other
FPGA technologies. I would recommend instead coding
reset explicitly (with a reset line).

Cheers,
Jim

Hmm...

sfixed_c is just a subtype defined to sfixed(32 downto -32).

However, when I try to do
in1, in2 : in sfixed(32 downto -32) := (others=>'0')

ISE tells me that "type of in1 is incompatible with type of aggregate".
Could it be that when I "mask" the type by using a subtype, ISE gets
confused?

(I can't actually test on the other code right now since I dont have it
with me)

How would I assign the inputs more explicitly? Or, do you mean just do
it inside of a process?

Thanks,

Sergey

Mike Treseler wrote:
Sergey Katsev wrote:
Thanks for your response Mike.

The element that it "dies" on should just be two flip-flops:

entity A1circ is
port( clk : in std_logic := '0';
X : in sfixed_c := (others=> '0'); -- input

I expect that sfixed_c type requires
a more specific assignment than (others=> '0');
Run vcom on the source for a better error description.

-- Mike Treseler
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Sergey Katsev wrote:

How would I assign the inputs more explicitly? Or, do you mean just do
it inside of a process?
Click to expand...
I would package a subtype:

subtype f32_t is sfixed(32 downto -32);
then declare the ports

in1, in2 : in f32_t := (f32_t'range=>'0');

Note that this init is ignored for synthesis
anyway, so another option might be to get rid of it.

-- Mike Treseler
 
Mike Treseler wrote:

subtype f32_t is sfixed(32 downto -32);
then declare the ports

in1, in2 : in f32_t := (f32_t'range=>'0');
Click to expand...
Sorry, I just noticed that your sfixed_c
is already a subtype such a subtype.

In that case

in1, in2 : in sfixed_c := (sfixed_c'range=>'0');

but as Jim just noted, you probably really want
to use a real reset.


-- Mike Treseler
 
"Andy" <jonesandy@comcast.net> wrote in message
news:1162326837.487846.157250@i42g2000cwa.googlegroups.com...
Does ISE accept negative indices on SLV? It seems like I've heard it
has problems with the ieee candidate fixed point package for that
reason.
Click to expand...
Unfortunately, you heard correctly.

In fact std_logic_vector is defined as an "array(natural range <>) of
std_logic"; consequently, negative indices are not allowed for slv anyway.
However, you can define your own logic array type (using integer range <>)
to get around this... and then XST will go ahead and barf at it.

I believe that the development team have been made aware of this (the
synthesizable fixed-point and floating-point libraries from the forthcoming
VHDL standards will certainly require support for this).

-Ben-
 
Thanks!

.... getting rid of the initialization (I'll worry about putting in a
reset later) made each individual component synthesize...

(and then my system ran out of RAM doing low-level synthesis, but I'll
try on a more powerful computer today and report back).

Thanks all!

-- Sergey

Mike Treseler wrote:
Mike Treseler wrote:

subtype f32_t is sfixed(32 downto -32);
then declare the ports

in1, in2 : in f32_t := (f32_t'range=>'0');

Sorry, I just noticed that your sfixed_c
is already a subtype such a subtype.

In that case

in1, in2 : in sfixed_c := (sfixed_c'range=>'0');

but as Jim just noted, you probably really want
to use a real reset.


-- Mike Treseler
Click to expand...
 
Andy,
I would rather have fixed point scaler types, maybe borrowing the ada
style, converted from "digits" to "bits" of course. The arithmetic
syntax would be much cleaner, and the results just as precise
(bit-accurate) as these vectors are, without the sizing headaches.
They'd simulate much faster than vectors too, approaching the
simulation performance of integers.
Click to expand...
I don't doubt any of this other than the "without the sizing headaches."
When you start working with sized objects (for synthesis), you need
to somehow specify how to handle the boundaries (saturating vs modulo
based wrap around, rounding vs truncation). Consider the following:

entity e is
end e ;
architecture a of e is

-- Numeric_std
signal Y_uv, A_uv, B_uv : unsigned(7 downto 0) ;
signal Z_uv : unsigned(8 downto 0) ;

-- fixed_pkg - in Accellera vhdl-2006
signal Y_uf, A_uf, B_uf : ufixed(7 downto 0) ;
signal Z_uf : ufixed(8 downto 0) ;

-- integer based math
signal Y_int, A_int, B_int : integer range 0 to 255 ;
signal Z_int : integer range 0 to 511 ;

begin

-- Numeric_Std natively does modulo based math
Y_uv <= A_uv + B_uv ;
Z_uv <= ('0' & A_uv) + B_uv ;

-- fixed_pkg natively does full precision math
Z_uf <= A_uf + B_uf ;
Y_uf <= resize(
arg => A_uf + B_uf, -- value
size_res => Y_uf, -- size of result
overflow_style => fixed_saturate, -- alternately fixed_wrap
round_style => fixed_round -- alternately fixed_truncate
) ;

-- integer based math does full precision math:
Z_int <= A_int + B_int ;
Y_int <= (A_int + B_int) mod 255 ; -- fixed_wrap

end a ;

How do I generate a saturated value for Y_int and Y_uv?
With the current resize, synthesis tools will need to be
somewhat smart as we don't need rounding for some operations
such as addition. The example above gets more interesting
when the integers have a signed range. A long range goal
would be for the methods that are used for the integer/scalar
fixed point/real based approach be the same as for the
package based approached (assume nothing is written in
stone - meaning we can add to the packages if necessary).

If I size integers, fixed point scalars (proposed by Andy)
and real, will I still get the simulation speed-up?
What if I need an integer bigger than 32 bits?
Do I need a switch or methodology that allows me to run
fast sims which ignore the sizing (but being big enough)
and accurate sims which use the sizing?

I think you have the start of something that is a good
idea. What we need is a passionate person who can champion
a language request into the Accellera VHDL requirements
committee and then work on the enhancement in the enhancements
group - note the enhancement is not the LRM text - LRM
changes are handled by a different group.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Jim,

With integers, the simulator is obliged to do, arithmetically, exactly
what you asked it to "or die trying". If I told it I wanted to put a +
b into a holder no bigger than b, it will do it or die trying. I don't
have to explicitly tell it that I want it to do the addition and then
resize the results to fit into something different.

Saturation with integers is similar to wrap, assuming you have a min()
function:

Y_int <= min(255, a_int + b_int); -- fixed_saturate

If these had been signed operands, it's a little more complex, but
still not too bad:

y_int <= max(0,min(255, a_int + b_int)); -- signed saturate

Alternatively, if there were additional attributes built in for
integers that indicated whether failure, saturation, or wrap was
desired behavior (with failure being the default for backwards
compatibility), then this would become moot. Like bounds checking, this
behavior would be applied only on assignment, not at the operator
level.

Even with the over/underflow resolution, whether it is done manually or
"behind the scenes", these integer operations will still simulate much
faster for any data size of more than a very few bits (maybe even 3 or
4 bits?). After all, the bounds checking is happening already,
executing the behavior is not much more work than that.

I have also been looking at the ada fixed point type declaration
mechanism to see if it is applicable/extendable to vhdl for hardware
specification. It seems pretty close as is, but I don't know enough
about how/if ada fixed point types can be subtyped, to allow a master
typedef (akin to integer) that is subtyped for synthesis size
constraints, to allow operations between different fixed point operands
(WRT bits and precision).

Andy

Jim Lewis wrote:
Andy,
I would rather have fixed point scaler types, maybe borrowing the ada
style, converted from "digits" to "bits" of course. The arithmetic
syntax would be much cleaner, and the results just as precise
(bit-accurate) as these vectors are, without the sizing headaches.
They'd simulate much faster than vectors too, approaching the
simulation performance of integers.

I don't doubt any of this other than the "without the sizing headaches."
When you start working with sized objects (for synthesis), you need
to somehow specify how to handle the boundaries (saturating vs modulo
based wrap around, rounding vs truncation). Consider the following:

entity e is
end e ;
architecture a of e is

-- Numeric_std
signal Y_uv, A_uv, B_uv : unsigned(7 downto 0) ;
signal Z_uv : unsigned(8 downto 0) ;

-- fixed_pkg - in Accellera vhdl-2006
signal Y_uf, A_uf, B_uf : ufixed(7 downto 0) ;
signal Z_uf : ufixed(8 downto 0) ;

-- integer based math
signal Y_int, A_int, B_int : integer range 0 to 255 ;
signal Z_int : integer range 0 to 511 ;

begin

-- Numeric_Std natively does modulo based math
Y_uv <= A_uv + B_uv ;
Z_uv <= ('0' & A_uv) + B_uv ;

-- fixed_pkg natively does full precision math
Z_uf <= A_uf + B_uf ;
Y_uf <= resize(
arg => A_uf + B_uf, -- value
size_res => Y_uf, -- size of result
overflow_style => fixed_saturate, -- alternately fixed_wrap
round_style => fixed_round -- alternately fixed_truncate
) ;

-- integer based math does full precision math:
Z_int <= A_int + B_int ;
Y_int <= (A_int + B_int) mod 255 ; -- fixed_wrap

end a ;

How do I generate a saturated value for Y_int and Y_uv?
With the current resize, synthesis tools will need to be
somewhat smart as we don't need rounding for some operations
such as addition. The example above gets more interesting
when the integers have a signed range. A long range goal
would be for the methods that are used for the integer/scalar
fixed point/real based approach be the same as for the
package based approached (assume nothing is written in
stone - meaning we can add to the packages if necessary).

If I size integers, fixed point scalars (proposed by Andy)
and real, will I still get the simulation speed-up?
What if I need an integer bigger than 32 bits?
Do I need a switch or methodology that allows me to run
fast sims which ignore the sizing (but being big enough)
and accurate sims which use the sizing?

I think you have the start of something that is a good
idea. What we need is a passionate person who can champion
a language request into the Accellera VHDL requirements
committee and then work on the enhancement in the enhancements
group - note the enhancement is not the LRM text - LRM
changes are handled by a different group.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Click to expand...
 
Andy,
With integers, the simulator is obliged to do, arithmetically, exactly
what you asked it to "or die trying". If I told it I wanted to put a +
b into a holder no bigger than b, it will do it or die trying. I don't
have to explicitly tell it that I want it to do the addition and then
resize the results to fit into something different.
Click to expand...
Exactly, so while the following assignment to Y_int will
work for many simulation runs, it will "die trying" if
A_int + B_int > 255. So if this condition never happens,
leaving it alone is ok, however, I also hope your testbench
generates all of the worst case values.

signal Y_int, A_int, B_int : integer range 0 to 255 ;
....
Y_int <= A_int + B_int ;


Even with the over/underflow resolution, whether it is done manually or
"behind the scenes", these integer operations will still simulate much
faster for any data size of more than a very few bits (maybe even 3 or
4 bits?). After all, the bounds checking is happening already,
executing the behavior is not much more work than that.
Click to expand...
My concern is that a 7 bit integer may simulate slower than
a 32 bit integer. Hence, for best speed, use a convenient
size that fits the value (but does not do fine grained bounds
checking - at 7 bit boundaries for example) and for accuracy,
use the exact size with exact bounds checking.


I have also been looking at the ada fixed point type declaration
mechanism to see if it is applicable/extendable to vhdl for hardware
specification. It seems pretty close as is, but I don't know enough
about how/if ada fixed point types can be subtyped, to allow a master
typedef (akin to integer) that is subtyped for synthesis size
constraints, to allow operations between different fixed point operands
(WRT bits and precision).
Click to expand...
Same problem with real, so something other than range would need to be
defined.

Long term, it would be beneficial if we had a usage methodology
that handled scalar and array numeric values in the same way.
This way, switching between scalar and array numeric types could
be as easy as switching a package and that contains a subtype
declaration:

package my_math_pkg is
subtype my_math_type is integer range 0 to 255 ;
end package my_math_pkg ;

Alternately in a separate file:
library ieee ;
use ieee.numeric_std.all ;
package my_math_pkg is
subtype my_math_type is unsigned(7 downto 0) ;
end package my_math_pkg ;

A more interesting case would to switch between a
a scalar fixed point type and real.

Cheers,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Jim,

Good discussion!

If I designed a circuit that should never need to roll over, I would
want to know about it as soon as it does, not have it silently roll
over all by itself. (That elementary arithmetic rule about a + 1 > a
always being true is important to me, and I want to know about it if it
is not going to be true) If it has the possibility of rolling over,
then I should handle that case they way I want to (i.e. saturate or
roll over), not the way signed/unsigned vectors do (always roll over).
The "extra" coding necessary to specify that behavior is small price to
pay (in performance, readability and typing) especially when compared
with that required of vector arithmetic, particularly if you wanted
saturation.

Incomplete testbenches are a fact of life, whether your
hardware/simulation automatically rolls over or not. If you did not
test the rollover with vectors in simulation, how do you know that is
acceptable? At least the integer simulation will tell you something is
wrong if it tried to do something you had not specified. The vector
simulation will happily, silently roll over and keep going, and you may
or may not notice the effects downstream. Consider what happens when SL
meta-values are encountered in an SLV based simulation: the synthesized
hardware does not behave the same there either. Pick your poison. I
prefer the poison that comes with blazing simulation speed.

As long as a 7 bit integer simulates many times faster than a 7 bit
vector, why worry about whether it simulates as fast as a 32 bit
integer? Some simulators do allow you to turn off bounds checking,
which would then simulate 7 bit integers as fast as 32 bit ones.

I too would like to be able to interchange scalar and vector types for
simulation efficiency vs hardware accuracy (i.e. 'X' resolution, etc.)
tradeoffs. Except for direct assignments using literals, you can do
that today in many cases: "a := (a + 1) mod 255"; works the same for
unsigned and natural today (assuming you're not using Synopsys!).
Unfortuanely, "a := 0" does not, nor does "a := (others => '0')". And
"a := min(255, a + 1)" does not work the same for both fixed(saturate)
and natural either. In an FPGA, with hardware initialization built in,
and no tri-state signals, the value of resolving 'X' is pretty low
compared to the speed of simulating integers. Consider how many more
corner cases you can excersize when your simulation is several times
quicker!

Switching between fixed and floating scalar types should be trivial...?
I hadn't even thought of that! It could come in really handy! Imagine
comparing two implementations of a design, one implemented with fixed
point, the other with floating point, in the same simulation...

Andy
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top