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
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…
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-200x-ft/packages/additions_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'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
-->
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;
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
>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
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
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
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
Any other ideas? Is there any hope of getting this to work in ISE? :)
-- Sergey
-- Sergey
You have to change synthesis tool from ISE 8 to any other. Synplicity
is currently one of the best to synthesis fixed_pkg (in my opinion..).
As I remember earlier I use ISE web Pack 8.2 with sp2 and some function
work correctly.
Try the newest ISE maybe it is help you:)
Additionally version 16 of fixed pkg is easiest to synthesis.
Mariusz
Thanks for your reply.
Unfortunately, ISE 8.2 is the latest one, and I don't have access to
Synplicity (this is for Grad. School, so I can't just have my company
pay for the software :) )
Are there any other free synthesis tools that will work? If not, any
ideas on synthesizing division? I guess I could synthesize without
division for now to show that my proof of concept is synthesizeable...
but that's not ideal.
-- Sergey
It's allowed. The fixed_pkg is based on numeric_std.
> 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.
fixed_pkg_c.vhdl (the vhdl 93 version) sfixed is based on an "array of
std_logic" not std_ulogic. Even "unresolved_sfixed" is based on
std_logic in this version.
The reason is the new types "unresolved_unsigned" and
"unresolved_signed" which will appear in the new version of numeric_std
(VHDL-2006). These are identical to the regular unsigned and signed,
but are based on unresolved logic. I wanted to put as much into the
vhdl-93 compatable package as possible, so I create these types based on
"std_logic_vector" so that they could be used.
SIGNED and UNSIGNED division is an issue with XST. To get this to work
in Xilinx I had to create a long division function.
Yes, ISE 8 was supposed to support these packages....
Sergey, did you try version 16 of fixed_pkg_c? I'm not sure if it'll
make a difference, but as Mariusz said, it is the easiest to get up
and running.
Richard
-- Sergey
>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 "/").
Yes, of course you are right. I'm sorry, I had not noticed in
your post that "+" was OK, and I have not tried negative
subscripts in XST recently myself.
Thanks
i've also been communicating with David Bishop and he's told me that
Synplicity should synthesize. I haven't been able to synthesize it but
I only get 4 errors and I'm hoping that someone could help me here with
those. I don't use division. In the current top entity, i'm only using
the conversion functions to_slv and to_sfixed.
The errors are in the fixed_synth_c.vhd file:
@E: CD415 :"/vhdl/sigmoid2/fixed_pkg_c.vhd":1164:61:1164:61|Expecting
keyword return
@E: CD428 :"/vhdl/sigmoid2/fixed_pkg_c.vhd":1461:21:1461:21|Duplicate
definition of package fixed_pkg
@E: CD200 :"/vhdl/sigmoid2/fixed_pkg_c.vhd":8083:4:8083:13|Misspelled
variable, signal or procedure name?
@E: CD415 :"/vhdl/sigmoid2/fixed_pkg_c.vhd":8604:26:8604:26|Expecting
keyword is
any hints?
thanks,
Danny