FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-28-2004, 05:58 AM
rickman
Guest
 
Posts: n/a
Default Strange XST error in ISE 6.3.02i

I have some code that compiles fine in Modelsim and under Quartus, but I
get an odd error under XST.

ERROR:HDLParsers:3324 -
//walmart800/allnetwork/arius/pc104c67/up/dinero/dinero/../OpcodeDefs.vhd
Line 128. IN mode Formal opcode of LIT with no default value must be
associated with an actual value.

The answer record on this error talks about passing generics into an
instance which is nothing like what I am doing. Here is a section of
the code in question.

type INSTDSPLY is (LIT, N0P,
CAL, RTI, JMP, JUMZ, JUMC, JUMO,
FTCH, STOR, FCHP, STRP, FCHB, STRB, FHPB, STPB,
DOOP, SWP, DRP, OVR, TORR, RFRM, RFTC,
RADT, RAD, RSB, RCM, RDRP,
ADNC, ADC, SBNC, SBC, CPNC, CPC, LAND, LOR, LXOR,
SHFL, SHFC, ZFLG, BFL, ERR);

function IRSLV_to_Inst (Opcode : IRSLV; LFLAG, BFLAG : STD_LOGIC)
return INSTDSPLY is
variable OpcodeInt : INSTVAL;
begin
if (Opcode(IRWdth-1) = '0') then
>>>>> return LIT; <<<<<< line number points here

elsif (Opcode = "10000000") then
return N0P;
elsif (not (Opcode(IRWdth-1) = '1' and
CountOnes(Opcode(IRWdth-2 downto 0)) = 3)) then
return ERR;
...
endif;
end IRSLV_to_Inst;

This function is being defined in a library package. It just looks up a
value of an SLV and returns an enumerated type for purpose of debug
display. Anyone have a clue? Is this an XST bug?

--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
  #2 (permalink)  
Old 10-29-2004, 01:47 AM
rickman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

I thought I would turn this over to Xilinx and open a case. But it
seems their web support makes you wait 24 hours. Did I do something
wrong? I was hoping to get this into the queue so it might get some
attention tomorrow before the weekend. But now it looks like I'll have
to wait until Monday.


rickman wrote:
>
> I have some code that compiles fine in Modelsim and under Quartus, but I
> get an odd error under XST.
>
> ERROR:HDLParsers:3324 -
> //walmart800/allnetwork/arius/pc104c67/up/dinero/dinero/../OpcodeDefs.vhd
> Line 128. IN mode Formal opcode of LIT with no default value must be
> associated with an actual value.
>
> The answer record on this error talks about passing generics into an
> instance which is nothing like what I am doing. Here is a section of
> the code in question.
>
> type INSTDSPLY is (LIT, N0P,
> CAL, RTI, JMP, JUMZ, JUMC, JUMO,
> FTCH, STOR, FCHP, STRP, FCHB, STRB, FHPB, STPB,
> DOOP, SWP, DRP, OVR, TORR, RFRM, RFTC,
> RADT, RAD, RSB, RCM, RDRP,
> ADNC, ADC, SBNC, SBC, CPNC, CPC, LAND, LOR, LXOR,
> SHFL, SHFC, ZFLG, BFL, ERR);
>
> function IRSLV_to_Inst (Opcode : IRSLV; LFLAG, BFLAG : STD_LOGIC)
> return INSTDSPLY is
> variable OpcodeInt : INSTVAL;
> begin
> if (Opcode(IRWdth-1) = '0') then
> >>>>> return LIT; <<<<<< line number points here

> elsif (Opcode = "10000000") then
> return N0P;
> elsif (not (Opcode(IRWdth-1) = '1' and
> CountOnes(Opcode(IRWdth-2 downto 0)) = 3)) then
> return ERR;
> ...
> endif;
> end IRSLV_to_Inst;
>
> This function is being defined in a library package. It just looks up a
> value of an SLV and returns an enumerated type for purpose of debug
> display. Anyone have a clue? Is this an XST bug?
>
> --
>
> Rick "rickman" Collins
>
> [email protected]
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX


--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
  #3 (permalink)  
Old 10-29-2004, 07:29 PM
John
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

Hi Rick,
Three things come to mind:

1) The error message seems to be objecting the formal input "opcode",
which is declared to be of type "IRSLV". Does changing the type to
"standard_logic_vector" help at all? Maybe XST gets confused over type
declarations.

2) Perhaps the problem is in the function usage rather than the
function itself. Can you show a code snippet where the function is
called?

3) I've had problems where stuff in a packaged library would not work
unless the library was first 'compiled' by running 'check syntax' on
the library package alone, separately from the design, in the ISE
environment. Maybe this would help?

HTH,
John (The Other John Smith)

rickman <[email protected]> wrote in message > > ERROR:HDLParsers:3324 -
> > //walmart800/allnetwork/arius/pc104c67/up/dinero/dinero/../OpcodeDefs.vhd
> > Line 128. IN mode Formal opcode of LIT with no default value must be
> > associated with an actual value.
> >
> > The answer record on this error talks about passing generics into an
> > instance which is nothing like what I am doing. Here is a section of
> > the code in question.
> >
> > type INSTDSPLY is (LIT, N0P,
> > CAL, RTI, JMP, JUMZ, JUMC, JUMO,
> > FTCH, STOR, FCHP, STRP, FCHB, STRB, FHPB, STPB,
> > DOOP, SWP, DRP, OVR, TORR, RFRM, RFTC,
> > RADT, RAD, RSB, RCM, RDRP,
> > ADNC, ADC, SBNC, SBC, CPNC, CPC, LAND, LOR, LXOR,
> > SHFL, SHFC, ZFLG, BFL, ERR);
> >
> > function IRSLV_to_Inst (Opcode : IRSLV; LFLAG, BFLAG : STD_LOGIC)
> > return INSTDSPLY is
> > variable OpcodeInt : INSTVAL;
> > begin
> > if (Opcode(IRWdth-1) = '0') then
> > >>>>> return LIT; <<<<<< line number points here

> > elsif (Opcode = "10000000") then
> > return N0P;
> > elsif (not (Opcode(IRWdth-1) = '1' and
> > CountOnes(Opcode(IRWdth-2 downto 0)) = 3)) then
> > return ERR;
> > ...
> > endif;
> > end IRSLV_to_Inst;
> >
> > This function is being defined in a library package. It just looks up a
> > value of an SLV and returns an enumerated type for purpose of debug
> > display. Anyone have a clue? Is this an XST bug?
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > [email protected]
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design URL http://www.arius.com
> > 4 King Ave 301-682-7772 Voice
> > Frederick, MD 21701-3110 301-682-7666 FAX

Reply With Quote
  #4 (permalink)  
Old 10-29-2004, 07:43 PM
rickman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

John wrote:
>
> Hi Rick,
> Three things come to mind:
>
> 1) The error message seems to be objecting the formal input "opcode",
> which is declared to be of type "IRSLV". Does changing the type to
> "standard_logic_vector" help at all? Maybe XST gets confused over type
> declarations.


I haven't tried that. I check.


> 2) Perhaps the problem is in the function usage rather than the
> function itself. Can you show a code snippet where the function is
> called?


This error happens when compiling the definition, not the useage. It
craps out on this file and never gets to the file where it is called.


> 3) I've had problems where stuff in a packaged library would not work
> unless the library was first 'compiled' by running 'check syntax' on
> the library package alone, separately from the design, in the ISE
> environment. Maybe this would help?


Yes, this is being compiled and not just syntax checked.

I am pretty convinced that this is an XST bug. The fact that it gives
the name LIT as the function name says something is pretty messed up.
But I am still open to the short between the headphones theory.

--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
  #5 (permalink)  
Old 10-29-2004, 10:01 PM
rickman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

rickman wrote:
>
> I thought I would turn this over to Xilinx and open a case. But it
> seems their web support makes you wait 24 hours. Did I do something
> wrong? I was hoping to get this into the queue so it might get some
> attention tomorrow before the weekend. But now it looks like I'll have
> to wait until Monday.


I just wanted to clarify this post. I guess the first time you use the
webcase page, you have to register, even if you are already registered
at the xilinx support site. I assume this to verify that you are
entitled to support. They take up to 24 hours to "approve" your
registration. Only when this is complete can you enter a case. That is
what I am waiting for.

I just wanted to make this clear because a Xilinx person saw my post and
had the mistaken impression that I had opened a case and was waiting for
someone to contact me. He took the initiative to call me and to open a
case for me. Thanks Ryan.

--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
  #6 (permalink)  
Old 11-01-2004, 10:14 AM
Alan Fitch
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i


"rickman" <[email protected]> wrote in message
news:[email protected]
> John wrote:
> >
> > Hi Rick,
> > Three things come to mind:
> >
> > 1) The error message seems to be objecting the formal input

"opcode",
> > which is declared to be of type "IRSLV". Does changing the type to
> > "standard_logic_vector" help at all? Maybe XST gets confused over

type
> > declarations.

>
> I haven't tried that. I check.
>
>
> > 2) Perhaps the problem is in the function usage rather than the
> > function itself. Can you show a code snippet where the function is
> > called?

>
> This error happens when compiling the definition, not the useage.

It
> craps out on this file and never gets to the file where it is

called.
>
>
> > 3) I've had problems where stuff in a packaged library would not

work
> > unless the library was first 'compiled' by running 'check syntax'

on
> > the library package alone, separately from the design, in the ISE
> > environment. Maybe this would help?

>
> Yes, this is being compiled and not just syntax checked.
>
> I am pretty convinced that this is an XST bug. The fact that it

gives
> the name LIT as the function name says something is pretty messed

up.
> But I am still open to the short between the headphones theory.
>



Just out of curiosity, does using a selected name work, e.g.

return packagename.INSTDSPLY

?

Alan


--
Alan Fitch
Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
[email protected]
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

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

Reply With Quote
  #7 (permalink)  
Old 11-01-2004, 07:34 PM
rickman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

Alan Fitch wrote:
>
> "rickman" <[email protected]> wrote in message
> news:[email protected]
> > John wrote:
> > >
> > > Hi Rick,
> > > Three things come to mind:
> > >
> > > 1) The error message seems to be objecting the formal input

> "opcode",
> > > which is declared to be of type "IRSLV". Does changing the type to
> > > "standard_logic_vector" help at all? Maybe XST gets confused over

> type
> > > declarations.

> >
> > I haven't tried that. I check.
> >
> >
> > > 2) Perhaps the problem is in the function usage rather than the
> > > function itself. Can you show a code snippet where the function is
> > > called?

> >
> > This error happens when compiling the definition, not the useage.

> It
> > craps out on this file and never gets to the file where it is

> called.
> >
> >
> > > 3) I've had problems where stuff in a packaged library would not

> work
> > > unless the library was first 'compiled' by running 'check syntax'

> on
> > > the library package alone, separately from the design, in the ISE
> > > environment. Maybe this would help?

> >
> > Yes, this is being compiled and not just syntax checked.
> >
> > I am pretty convinced that this is an XST bug. The fact that it

> gives
> > the name LIT as the function name says something is pretty messed

> up.
> > But I am still open to the short between the headphones theory.
> >

>
> Just out of curiosity, does using a selected name work, e.g.
>
> return packagename.INSTDSPLY


Just like I suspected all along, it was a user error. I had a function
with the same name as an enumeration value. The other tools seemed to
figure it out by context, but XST didn't like it.

So I have fixed that, but I am getting another set of errors where it
does not like my constants I think. I have defined a set of constant
SLVs to match my opcodes. To make defining them easier I entered their
values as function calls...

constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 - 00
constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 - 80
constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 - 87

INSTBITS is an array of three integers (range 0 to 7) which TO_INTEGER
converts to a single integer equal to the weighted sum, (i.e. binary
positions to integer value). Logically this works and again, two other
tools compile this just fine. XST barfs when I try to use one of these
constants as a case statement choice saying "Choice call is not a
locally static expression". Does the use of a function in a constant
initialization make the constant not "locally static"? I tried looking
in the LRM for a definition of "locally static" and could not find it.

I did find on a web page that a locally static expression (LSE) can be
either a literal, a constant that is init'd by an LSE or a call to an
"implicitly predefined operator". So I guess my function calls make my
constants only globally static and not locally static?

--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
  #8 (permalink)  
Old 11-02-2004, 10:23 AM
Alan Fitch
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i


"rickman" <[email protected]> wrote in message
news:[email protected]
<snip>
> Just like I suspected all along, it was a user error. I had a

function
> with the same name as an enumeration value. The other tools seemed

to
> figure it out by context, but XST didn't like it.
>
> So I have fixed that, but I am getting another set of errors where

it
> does not like my constants I think. I have defined a set of

constant
> SLVs to match my opcodes. To make defining them easier I entered

their
> values as function calls...
>
> constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 -

00
> constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 -

80
> constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 -

87
>
> INSTBITS is an array of three integers (range 0 to 7) which

TO_INTEGER
> converts to a single integer equal to the weighted sum, (i.e. binary
> positions to integer value). Logically this works and again, two

other
> tools compile this just fine. XST barfs when I try to use one of

these
> constants as a case statement choice saying "Choice call is not a
> locally static expression". Does the use of a function in a

constant
> initialization make the constant not "locally static"? I tried

looking
> in the LRM for a definition of "locally static" and could not find

it.
>
> I did find on a web page that a locally static expression (LSE) can

be
> either a literal, a constant that is init'd by an LSE or a call to

an
> "implicitly predefined operator". So I guess my function calls make

my
> constants only globally static and not locally static?
>


Something that is locally static can have its value determined purely
during analysis of that design unit, it doesn't require elaboration
of the complete design hierarchy.

The standard defines static and locally static in section 7.4.

It does look to me as though XST may be correct, as it says that
a constant is only locally static if it is initialized by a locally
static primary (which doesn't include a function call).

I don't understand what your TO_INTEGER function does, sorry :-(

Alan

--
Alan Fitch
Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
[email protected]
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

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

Reply With Quote
  #9 (permalink)  
Old 11-02-2004, 11:27 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

On Tue, 2 Nov 2004 09:23:56 -0000, "Alan Fitch"
<[email protected]> wrote:

>
>"rickman" <[email protected]> wrote in message
>news:[email protected]
><snip>
>> Just like I suspected all along, it was a user error. I had a

>function
>> with the same name as an enumeration value. The other tools seemed

>to
>> figure it out by context, but XST didn't like it.
>>
>> So I have fixed that, but I am getting another set of errors where

>it
>> does not like my constants I think. I have defined a set of

>constant
>> SLVs to match my opcodes. To make defining them easier I entered

>their
>> values as function calls...
>>
>> constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 -

>00
>> constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 -

>80
>> constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 -

>87
>>
>> INSTBITS is an array of three integers (range 0 to 7) which

>TO_INTEGER
>> converts to a single integer equal to the weighted sum, (i.e. binary
>> positions to integer value). Logically this works and again, two

>other
>> tools compile this just fine. XST barfs when I try to use one of

>these
>> constants as a case statement choice saying "Choice call is not a
>> locally static expression". Does the use of a function in a

>constant
>> initialization make the constant not "locally static"? I tried

>looking
>> in the LRM for a definition of "locally static" and could not find

>it.
>>
>> I did find on a web page that a locally static expression (LSE) can

>be
>> either a literal, a constant that is init'd by an LSE or a call to

>an
>> "implicitly predefined operator". So I guess my function calls make

>my
>> constants only globally static and not locally static?
>>

>
>Something that is locally static can have its value determined purely
>during analysis of that design unit, it doesn't require elaboration
>of the complete design hierarchy.
>
>The standard defines static and locally static in section 7.4.
>
>It does look to me as though XST may be correct, as it says that
>a constant is only locally static if it is initialized by a locally
>static primary (which doesn't include a function call).
>
>I don't understand what your TO_INTEGER function does, sorry :-(


I understand that the new version of VHDL will remove this restriction
and allow globally static expressions to be used in case statements.

Regards,
Allan
Reply With Quote
  #10 (permalink)  
Old 11-02-2004, 11:44 PM
rickman
Guest
 
Posts: n/a
Default Re: Strange XST error in ISE 6.3.02i

Alan Fitch wrote:
>
> Something that is locally static can have its value determined purely
> during analysis of that design unit, it doesn't require elaboration
> of the complete design hierarchy.
>
> The standard defines static and locally static in section 7.4.


Thanks. It says a function call has to be an "implicitly defined
operator", which I can't find a meaning for.


> It does look to me as though XST may be correct, as it says that
> a constant is only locally static if it is initialized by a locally
> static primary (which doesn't include a function call).


It doesn't include the word "primary", just initialized by a locally
static expression.

> I don't understand what your TO_INTEGER function does, sorry :-(


It just converts and array of three integers to another integer by
treating them as exponents of 2 and summing them. The binary number
11010 could be represented as (1, 3, 4) which would be evaluated as 26
decimal. This was just to allow me to input my info in the form it was
already in. Not a biggie, I have already fixed it by making it an
expression.

--

Rick "rickman" Collins

[email protected]
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
strange error gilbert FPGA 0 03-07-2004 01:39 PM
spartan2 pin LOC strange error lnguyen FPGA 0 12-10-2003 07:13 PM
Strange error in Quartus II 3.0 Panic FPGA 6 10-22-2003 07:46 PM


All times are GMT +1. The time now is 06:22 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved