VHDL Fixed Point package...

S

Sergey Katsev

Guest
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
Click to expand...
 
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-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
 
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
-->

rnbrady@gmail.com 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-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
Click to expand...
 
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;


rnbrady@gmail.com 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-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
Click to expand...
 
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;


rnbrady@gmail.com 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-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
Click to expand...
 
On 13 Oct 2006 04:15:35 -0700, rnbrady@gmail.com wrote:


Where Modelsim can happily resolve the difference between "+" based on
whether the argument is "signed" or "sfixed,"
Click to expand...
yes

these are actually
subtypes based on the same "array of std_ulogic" type.
Click to expand...
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
Click to expand...
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.bromley@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.
 
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
Click to expand...

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, rnbrady@gmail.com 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.
Click to expand...
 
rnbrady@gmail.com 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;


rnbrady@gmail.com 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-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 commented out numeric_std (it wasn't needed anyway), and the same
Click to expand...
problem persists...

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

-- Sergey
 
.... also Synthesizes fine for "*", so it seems that its a
division-specific problem. Doesn't seem to have to do with the negative
indeces. (I think I saw somewhere that ISE 7 can't handle negative
indeces, but ISE 8 can...)

-- Sergey

rnbrady@gmail.com 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;


rnbrady@gmail.com 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-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
Click to expand...
 
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
 
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

MariuszK wrote:
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
Click to expand...
 
rnbrady@gmail.com 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.
Click to expand...
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.
Click to expand...
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.
 
Sergey Katsev wrote:
... also Synthesizes fine for "*", so it seems that its a
division-specific problem. Doesn't seem to have to do with the negative
indeces. (I think I saw somewhere that ISE 7 can't handle negative
indeces, but ISE 8 can...)
Click to expand...
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....
 
OK, I think I understand. Thanks Andy, Jonathan and David for clearing
that up. This language can be a bit mind-boggling at times, but what
you say makes perfect sense.

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
 
Yes, that's the version that I was able so synthesize +, -, * with...
but / doesn't work.

-- Sergey

rnbrady@gmail.com wrote:
OK, I think I understand. Thanks Andy, Jonathan and David for clearing
that up. This language can be a bit mind-boggling at times, but what
you say makes perfect sense.

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
Click to expand...
 
On Fri, 13 Oct 2006 12:03:31 -0400, Sergey Katsev
<sergey.katsev@coyotepoint.com> wrote:

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 "/").
Click to expand...
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
--
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.bromley@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.
 
Sergey Katsev wrote:
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).
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top