Syntax check not catching error

[marc rei]

In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why? Is there a way to set it up to do so?

 

[KJ]

marc rei wrote:

In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why?
It didn't "catch it" because it is not an error. It may not be what

you want, but it is valid syntax. The "<=" in an 'if' statement means
"less than or equal to" not "signal assignment" if that's what you're
thinking.

Is there a way to set it up to do so?
I hope not....

KJ

 

[Paul Uiterlinden]

marc rei wrote:

In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why? Is there a way to set it up to do so?

Because it's not a syntax error. Signal probably is of type
std_(u)logic (or even bit). That's an enumeration type. It is legal
to use relational operators such as <= (less than or equal) on
enumeration types.

std_ulogic is defined as ('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', '-')

So for values 'U', 'X', '0' and '1' your equation yields true, for
'Z', 'W', 'L', 'H' and '-' it will be false.

I wonder how it will be synthesized. I guess as "always true". In that
case, a warning would have been nice.

--
Paul.
www.aimcom.nl

 

[marc rei]

Unfortunately it is defined as std_logic and is found several times in
the project.

Paul Uiterlinden wrote:

marc rei wrote:

In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why? Is there a way to set it up to do so?

Because it's not a syntax error. Signal probably is of type
std_(u)logic (or even bit). That's an enumeration type. It is legal
to use relational operators such as <= (less than or equal) on
enumeration types.

std_ulogic is defined as ('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', '-')

So for values 'U', 'X', '0' and '1' your equation yields true, for
'Z', 'W', 'L', 'H' and '-' it will be false.

I wonder how it will be synthesized. I guess as "always true". In that
case, a warning would have been nice.

--
Paul.
www.aimcom.nl

 

[KJ]

marc rei wrote:

Unfortunately it is defined as std_logic and is found several times in
the project.

Is there some question here? Your original post said that this is from

legacy code so I presume it must be 'working' legacy code (i.e.
performs the proper function). As explained previously, the syntax of
the statement is not an error so what is your question?

KJ

 

[Jim Lewis]

marc rei wrote:

In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why? Is there a way to set it up to do so?

"<=" is overloadable. Reference the attached package.
There are two possible outcomes.
1: Compile time error: Older simulators do not allow explicit
implementations of subprograms to overload implicit ones (newer ones do).

2: Run time warning due to code in package.

Option 2: Make a copy of the attached package under a different
name and reference both packages in the design - the result
is a compile time error flagging the operator.

Have fun,
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KJ]

"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:12jgbvrc3n5bp9a@corp.supernews.com...

marc rei wrote:
In some legacy code I found:
if (signal <= '1') then...
But the Xilinx ISE syntax check did NOT catch this.
Why? Is there a way to set it up to do so?


"<=" is overloadable. Reference the attached package.
There are two possible outcomes.
1: Compile time error: Older simulators do not allow explicit
implementations of subprograms to overload implicit ones (newer ones
do).

2: Run time warning due to code in package.

Option 2: Make a copy of the attached package under a different
name and reference both packages in the design - the result
is a compile time error flagging the operator.

Well Jim, that's just plain cheating. The original post was complaining
about a non-existent syntax error and now you're giving instructions for how
to insert errors into the code in order to smoke out the error that didn't
exist

KJ