«

All,

I’m using Xilinx WebPack ISE 8, and the project is just “fixed_synth”
with “fixed_pkg” and “math_utility_pkg” in IEEE_PROPOSED.



After removing some incompatibilities (such as aliases), I get these errors:



Compiling vhdl file "/vhdl/math_utility_pkg.vhdl" in Library ieee_proposed.

Compiling vhdl file "/vhdl/fixed_pkg_c_new.vhdl" in Library ieee_proposed.

WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1478. Null
range: 0 downto 1

WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1479. Null
range: 0 downto 1

WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1480. Null
range: 0 downto 1

Architecture fixed_pkg of Entity fixed_pkg is up to date.

Compiling vhdl file "/vhdl/fixed_synth.vhdl" in Library work.

Entity <fixed_synth> compiled.

ERROR:HDLParsers:163 - "/vhdl/fixed_synth.vhdl" Line 659. Unexpected
symbol read: ?.

ERROR:HDLParsers:800 - "/vhdl/fixed_synth.vhdl" Line 659. Type of
outarray is incompatible with type of =.

ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 670. parse error,
unexpected NOR

ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 671. parse error,
unexpected XNOR

ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 672. parse error,
unexpected NAND

ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 673. parse error,
unexpected OR



Is it actually not “understanding” the VHDL, or am I setting up the
project incorrectly?

Thanks in advance,

Sergey

Some background information:

I’ve tried to get the VHDL 2006 (’93 compatibility) fixed point
libraries to synthesize, but have thus far been unsuccessful. I have a
full version of Xilinx ISE 7.1i as well as the Xilinx Webpack ISE 8.2
(the most recent version). I can get the packages to compile and
simulate using ModelSim, but get tons of errors when I try to synthesize.



Any clues? For now, I’d just like to synthesize *something* that uses
this package…




Sergey Katsev wrote:
>
> All,
>
> I’m using Xilinx WebPack ISE 8, and the project is just “fixed_synth”
> with “fixed_pkg” and “math_utility_pkg” in IEEE_PROPOSED.
>
>
>
> After removing some incompatibilities (such as aliases), I get these
> errors:
>
>
>
> Compiling vhdl file "/vhdl/math_utility_pkg.vhdl" in Library ieee_proposed.
>
> Compiling vhdl file "/vhdl/fixed_pkg_c_new.vhdl" in Library ieee_proposed.
>
> WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1478. Null
> range: 0 downto 1
>
> WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1479. Null
> range: 0 downto 1
>
> WARNING:HDLParsers:3350 - "/vhdl/fixed_pkg_c_new.vhdl" Line 1480. Null
> range: 0 downto 1
>
> Architecture fixed_pkg of Entity fixed_pkg is up to date.
>
> Compiling vhdl file "/vhdl/fixed_synth.vhdl" in Library work.
>
> Entity <fixed_synth> compiled.
>
> ERROR:HDLParsers:163 - "/vhdl/fixed_synth.vhdl" Line 659. Unexpected
> symbol read: ?.
>
> ERROR:HDLParsers:800 - "/vhdl/fixed_synth.vhdl" Line 659. Type of
> outarray is incompatible with type of =.
>
> ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 670. parse error,
> unexpected NOR
>
> ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 671. parse error,
> unexpected XNOR
>
> ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 672. parse error,
> unexpected NAND
>
> ERROR:HDLParsers:164 - "/vhdl/fixed_synth.vhdl" Line 673. parse error,
> unexpected OR
>
>
>
> Is it actually not “understanding” the VHDL, or am I setting up the
> project incorrectly?
>
> Thanks in advance,
>
> Sergey

Sergey

OK, I presume you downloaded the latest version off the web. I just got
it and tried to run it, and also got errors. I tihnk it might be in a
state of flux right now. I'm using the previous version which you can
get from
http://www.vhdl.org/vhdl-200x/vhdl-2...tions_16.tar.Z

If you use it you don't need the utility package. Give it a try and see
what happens. Also, to start with, maybe don't try and synthesize
fixed_syth.vhd. Rather write your own vhdl file with a single entity
that just does a single fixed point multiply. Then see if you can get
that to work.

Richard

Thanks for your help Richard.

I've been able to get it to Synthesize a "+" operation, but this is what
I get for a "/" (even though ModelSim simulates fine).

With "+", it's just a simple adder... and its more complicated for the
divide. Any ideas?


================================================== =======================
* HDL Analysis *
================================================== =======================
Analyzing Entity <fixed_synth> in library <work> (Architecture <rtl>).
INFO:Xst:1749 - "C:/Documents and Settings/Sergey
Katsev/Desktop/vhdl/moo2/fixed_pkg_c.vhd" line 2020: report:
FIXED_GENERIC_PKG.DIVIDE uFixed point Division by zero
ERROR:Xst:769 - "C:/Documents and Settings/Sergey
Katsev/Desktop/vhdl/moo2/fixed_pkg_c.vhd" line 2023: Operator <INVALID
OPERATOR> must have constant operands or first operand must be power of 2

Thanks again in advance,

Sergey
-->

wrote:
> Sergey
>
> OK, I presume you downloaded the latest version off the web. I just got
> it and tried to run it, and also got errors. I tihnk it might be in a
> state of flux right now. I'm using the previous version which you can
> get from
> http://www.vhdl.org/vhdl-200x/vhdl-2...tions_16.tar.Z
>
> If you use it you don't need the utility package. Give it a try and see
> what happens. Also, to start with, maybe don't try and synthesize
> fixed_syth.vhd. Rather write your own vhdl file with a single entity
> that just does a single fixed point multiply. Then see if you can get
> that to work.
>
> Richard
>

Here's the test file I'm using:

library ieee;
library ieee_proposed;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee_proposed.math_utility_pkg.all;
use ieee_proposed.fixed_pkg.all;
entity fixed_synth is

port (
in1, in2 : in ufixed (4 downto -5); -- inputs
out1 : out ufixed (4 downto -5); -- output
clk, rst_n : in STD_ULOGIC); -- clk and reset

end entity fixed_synth;

architecture rtl of fixed_synth is
signal outarray : ufixed (4 downto -5);

begin -- architecture rtl
-- purpose: "0010" test the "*" operator

moo: process (clk)
begin
if (rising_edge(clk)) then
outarray <= resize(in1 / in2, 4, -5);
end if;
end process moo;

out1 <= outarray;


end architecture rtl;


wrote:
> Sergey
>
> OK, I presume you downloaded the latest version off the web. I just got
> it and tried to run it, and also got errors. I tihnk it might be in a
> state of flux right now. I'm using the previous version which you can
> get from
> http://www.vhdl.org/vhdl-200x/vhdl-2...tions_16.tar.Z
>
> If you use it you don't need the utility package. Give it a try and see
> what happens. Also, to start with, maybe don't try and synthesize
> fixed_syth.vhd. Rather write your own vhdl file with a single entity
> that just does a single fixed point multiply. Then see if you can get
> that to work.
>
> Richard
>

Sergey

I see that you are using ieee.numeric_std in the same file, and I'm not
sure if this is allowed. I think it introduces function/operator
overloading, and in my experience there are vendor specific subtleties
in how this is handled.

Where Modelsim can happily resolve the difference between "+" based on
whether the argument is "signed" or "sfixed," these are actually
subtypes based on the same "array of std_ulogic" type. The standard
doesn't allow resolution based on subtypes, so that might explain why
ISE can't tell the difference. I stand to be corrected on this, perhaps
one of the guru's can clarify.

Anyway, try taking numeric_std out and see what happens.

Richard






Sergey Katsev wrote:
> Here's the test file I'm using:
>
> library ieee;
> library ieee_proposed;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> use ieee_proposed.math_utility_pkg.all;
> use ieee_proposed.fixed_pkg.all;
> entity fixed_synth is
>
> port (
> in1, in2 : in ufixed (4 downto -5); -- inputs
> out1 : out ufixed (4 downto -5); -- output
> clk, rst_n : in STD_ULOGIC); -- clk and reset
>
> end entity fixed_synth;
>
> architecture rtl of fixed_synth is
> signal outarray : ufixed (4 downto -5);
>
> begin -- architecture rtl
> -- purpose: "0010" test the "*" operator
>
> moo: process (clk)
> begin
> if (rising_edge(clk)) then
> outarray <= resize(in1 / in2, 4, -5);
> end if;
> end process moo;
>
> out1 <= outarray;
>
>
> end architecture rtl;
>
>
> wrote:
> > Sergey
> >
> > OK, I presume you downloaded the latest version off the web. I just got
> > it and tried to run it, and also got errors. I tihnk it might be in a
> > state of flux right now. I'm using the previous version which you can
> > get from
> > http://www.vhdl.org/vhdl-200x/vhdl-2...tions_16.tar.Z
> >
> > If you use it you don't need the utility package. Give it a try and see
> > what happens. Also, to start with, maybe don't try and synthesize
> > fixed_syth.vhd. Rather write your own vhdl file with a single entity
> > that just does a single fixed point multiply. Then see if you can get
> > that to work.
> >
> > Richard
> >

On 13 Oct 2006 04:15:35 -0700, wrote:


>Where Modelsim can happily resolve the difference between "+" based on
>whether the argument is "signed" or "sfixed,"

yes

> these are actually
>subtypes based on the same "array of std_ulogic" type.

urrm, I don't think so... they are completely different named types;
they are, indeed, both arrays of std_logic (not std_ulogic, I think)
but because they have different *type* names, the overloads
are resolvable. That's the reason why, for example, you can
have different ">" operators for numeric_std.signed and
numeric_std.unsigned, both of which are arrays of std_logic.

> The standard
>doesn't allow resolution based on subtypes

This is true, but as I hope I've explained above, it's not the
problem here.

I'm not sure what the situation is right now, but I'm fairly sure you
will find that the problem relates to the negative subscripts that the
IEEE fixed-point packages permit. Simulators are fine with negative
subscripts, but I don't think ISE accepts them yet - although, of
course, the VHDL-2006 people are working hard to get synthesis
tool vendors to accept them. When I did my own effort at
fixed-point (now completely superseded by the VHDL-2006 version)
I used a subscript offset scheme so that I didn't need to use
negative subscripts - I chose subscript=100 for the units bit,
so subscript 99 was the "half" bit and so on.

Another issue is that the packages can occasionally create
objects with a null range, such as sfixed(0 downto 1). Again
this is perfectly legal VHDL, but synthesis tools tend to object.

It would be great if someone could do a definitive survey
of which synthesis tools are currently OK with negative
subscripts and null ranges.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Sergey Katsev wrote:
> Thanks for your help Richard.
>
> I've been able to get it to Synthesize a "+" operation, but this is what
> I get for a "/" (even though ModelSim simulates fine).
>
> With "+", it's just a simple adder... and its more complicated for the
> divide. Any ideas?
>
>
> ================================================== =======================
> * HDL Analysis *
> ================================================== =======================
> Analyzing Entity <fixed_synth> in library <work> (Architecture <rtl>).
> INFO:Xst:1749 - "C:/Documents and Settings/Sergey
> Katsev/Desktop/vhdl/moo2/fixed_pkg_c.vhd" line 2020: report:
> FIXED_GENERIC_PKG.DIVIDE uFixed point Division by zero
> ERROR:Xst:769 - "C:/Documents and Settings/Sergey
> Katsev/Desktop/vhdl/moo2/fixed_pkg_c.vhd" line 2023: Operator <INVALID
> OPERATOR> must have constant operands or first operand must be power of 2
>


I suspect XST doesn't support the numeric_std division operator which I
think is a requirement for a fixed point divide.

Synthesis of division operators has taken a very long time to become
supported for the simple reason the circuits it creates are fairly
impractical (slow and huge). Generally there's a better way to
implement whatever you require without chucking away half your chip.

Cheers,

Andy

David Bishop told me a few days ago that Synplicity should synthesize
the Fixed Point package without any issues (I don't have access to
Synplicity, so I can't verify).

Wouldn't ISE have issues synthesizing the "+" code also, if it couldn't
handle negative subscripts? (It's the same code as what I posted
yesterday, but "+" instead of "/").

-- Sergey

Jonathan Bromley wrote:
> On 13 Oct 2006 04:15:35 -0700, wrote:
>
>
>> Where Modelsim can happily resolve the difference between "+" based on
>> whether the argument is "signed" or "sfixed,"
>
> yes
>
>> these are actually
>> subtypes based on the same "array of std_ulogic" type.
>
> urrm, I don't think so... they are completely different named types;
> they are, indeed, both arrays of std_logic (not std_ulogic, I think)
> but because they have different *type* names, the overloads
> are resolvable. That's the reason why, for example, you can
> have different ">" operators for numeric_std.signed and
> numeric_std.unsigned, both of which are arrays of std_logic.
>
>> The standard
>> doesn't allow resolution based on subtypes
>
> This is true, but as I hope I've explained above, it's not the
> problem here.
>
> I'm not sure what the situation is right now, but I'm fairly sure you
> will find that the problem relates to the negative subscripts that the
> IEEE fixed-point packages permit. Simulators are fine with negative
> subscripts, but I don't think ISE accepts them yet - although, of
> course, the VHDL-2006 people are working hard to get synthesis
> tool vendors to accept them. When I did my own effort at
> fixed-point (now completely superseded by the VHDL-2006 version)
> I used a subscript offset scheme so that I didn't need to use
> negative subscripts - I chose subscript=100 for the units bit,
> so subscript 99 was the "half" bit and so on.
>
> Another issue is that the packages can occasionally create
> objects with a null range, such as sfixed(0 downto 1). Again
> this is perfectly legal VHDL, but synthesis tools tend to object.
>
> It would be great if someone could do a definitive survey
> of which synthesis tools are currently OK with negative
> subscripts and null ranges.

wrote:
> Sergey
>
> I see that you are using ieee.numeric_std in the same file, and I'm not
> sure if this is allowed. I think it introduces function/operator
> overloading, and in my experience there are vendor specific subtleties
> in how this is handled.
>
> Where Modelsim can happily resolve the difference between "+" based on
> whether the argument is "signed" or "sfixed," these are actually
> subtypes based on the same "array of std_ulogic" type. The standard
> doesn't allow resolution based on subtypes, so that might explain why
> ISE can't tell the difference. I stand to be corrected on this, perhaps
> one of the guru's can clarify.
>
> Anyway, try taking numeric_std out and see what happens.
>
> Richard
>
>
>
>
>
>
> Sergey Katsev wrote:
>> Here's the test file I'm using:
>>
>> library ieee;
>> library ieee_proposed;
>> use ieee.std_logic_1164.all;
>> use ieee.numeric_std.all;
>> use ieee_proposed.math_utility_pkg.all;
>> use ieee_proposed.fixed_pkg.all;
>> entity fixed_synth is
>>
>> port (
>> in1, in2 : in ufixed (4 downto -5); -- inputs
>> out1 : out ufixed (4 downto -5); -- output
>> clk, rst_n : in STD_ULOGIC); -- clk and reset
>>
>> end entity fixed_synth;
>>
>> architecture rtl of fixed_synth is
>> signal outarray : ufixed (4 downto -5);
>>
>> begin -- architecture rtl
>> -- purpose: "0010" test the "*" operator
>>
>> moo: process (clk)
>> begin
>> if (rising_edge(clk)) then
>> outarray <= resize(in1 / in2, 4, -5);
>> end if;
>> end process moo;
>>
>> out1 <= outarray;
>>
>>
>> end architecture rtl;
>>
>>
>> wrote:
>>> Sergey
>>>
>>> OK, I presume you downloaded the latest version off the web. I just got
>>> it and tried to run it, and also got errors. I tihnk it might be in a
>>> state of flux right now. I'm using the previous version which you can
>>> get from
>>> http://www.vhdl.org/vhdl-200x/vhdl-2...tions_16.tar.Z
>>>
>>> If you use it you don't need the utility package. Give it a try and see
>>> what happens. Also, to start with, maybe don't try and synthesize
>>> fixed_syth.vhd. Rather write your own vhdl file with a single entity
>>> that just does a single fixed point multiply. Then see if you can get
>>> that to work.
>>>
>>> Richard
>>>
>
I commented out numeric_std (it wasn't needed anyway), and the same
problem persists...

Any other ideas? Is there any hope of getting this to work in ISE?

-- Sergey