Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Synplify error message while synthisizing a VHDL code

Status
Not open for further replies.

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello people:

What do you think about the following code:

constant x: std_logic_vector( (conv_integer(y) - 1 downto 0) ) := (others => '1');
-- y is a std_logic_vector defined in the entity generics

Xilinx ISE synthesizes this code with no issue while SynplifyPro terminates it with the following error message:
"Expression <E70> does not have a position value"

Please advise...
 

Any reason why you don't use integer generics? conv_integer() result may be undefined unless you qualify the argument as unsigned.
 

yes, there's a reason.
I use this generic to indicate the highest address of memory stack...I want it to overflow to (others => '0') when a value reaches this address.
For example: if it's "1111" and '1' is added it will overflow to "0000".
So while "1111" + '1' = "0000" the integer equivalent won't apply because 15 + 1 /= 0
 

yes, there's a reason.
I use this generic to indicate the highest address of memory stack...I want it to overflow to (others => '0') when a value reaches this address.
For example: if it's "1111" and '1' is added it will overflow to "0000".
So while "1111" + '1' = "0000" the integer equivalent won't apply because 15 + 1 /= 0

conv_integer is not a standard function.
You should not use it if you use numeric_std. Use to_integer instead.

In your first post, why would the end result be different if 'y' was an integer? The constant 'x' will be a std_logic_vector anyway.

In this case, why not use "unsigned" (in numeric_std) for the stack pointer?
An unsigned "1111" will wrap to "0000" if you increment it.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
std_match,

The end result of y won't be different if it was defined as an integer - but I needed it to be a vector so it could wrap.
I use y as a generic for the top address and I define it as a vector so it would wrap...

I don't understand your suggestion.
Are you saying that if y is defined as an unsigned integer it would wrap like a vector?
 

constant x: std_logic_vector( (conv_integer(y) - 1 downto 0) ) := (others => '1');
-- y is a std_logic_vector defined in the entity generics
I don't understand what "y" is. Is it a std_logic_vector that defines how many bits "x" will have?
"x" can have many more bits than "y". Is that what you want?

shaiko said:
Are you saying that if y is defined as an unsigned integer it would wrap like a vector?

No, "unsigned" in numeric_std is not an unsigned integer. It is a std_logic_vector interpreted as an unsigned number.
You define the number of bits as for std_logic_vector, and you can do mathematical operations directly.
The number of bits in the result of a mathematical operation is the same as the largest unsigned/signed involved.
If you increment an unsigned with all bits = '1', it will wrap to all zeros.

Code:
signal x: unsigned(3 downto 0);

x <= x + 1;
"x" is defined as a 4-bit unsigned number, and it will wrap automatically between "1111" and "0000".

unsigned/signed signals should be your first choice if you want to do simple mathematical operations. They are also useful types for ports.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Thanks for the information.
I think I'll start using "unsigned" instead of "std_logic_vector"...

Fvm,
about 'y'.
It indeed makes no scene to conv_integer an integer...I thought that I defined it as a vector the conversion function is redundant.
 

The thread shows the problem of discussing a one-line snippet. We don't know the imported libraries or other context informations.

Referring to the original problem, the type of a generic hasn't to do with signals wrapping around, because generics are constant values. Generics used in arithmetic expressions evaluated at compile time have integer as an obvious type in my view. A modulo operator is available for compile time operations as well. Bit masks or initialization constants are good as bit vectors.
 

Sure,
The integer generic is just a constant.
But I use it to evaluate a signal of typed "std_logic_vector" which isn't a constant.
Therefore I want it to wrap...

If x is a constant of type std_logic_vector ("1111"), the following applies:

"1111" + '1' = "0000"

If x is an integer - evaluating it the same way won't work
 

also, you have too many parens.

I'm not sure if std_logic_vector((1 downto 0)) is even valid.
 

A comparison of a signed or unsigned bit vector with an integer expression, e.g. if (i + 1) mod 16 = u however works.

Or if i = u1-u2

Also add and sub of unsigned/signed bit vector and integer constant are defined operations
if i = u - 1
 
Last edited:
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
FvM,

signal some_interger; -- integer of 32 bit width
some_interger <= 15;

(some_integer + 1) mod 4 = "0000"
(some_integer + 2) mod 4 = "0001"

Will the comparison be true or false?
 

I guess, you would use mod 16 for a bit vector of length 4. But both comparisons are true. (15 + 2) mod 4 or (15 + 2) mod 16 have both a result of 1.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
it wont work as it is, because it is ambiguous - the compile wont know if the string is a signed or unsigned type. You will need to either convert the integer or qualify the string.

to_Unsigned( (some_integer + 1) mod 4, 4) = "0000"

or

(some_integer + 1) mod 4 = unsigned'("0000")

---------- Post added at 11:15 ---------- Previous post was at 11:11 ----------

No, "unsigned" in numeric_std is not an unsigned integer. It is a std_logic_vector interpreted as an unsigned number.

Sorry - saw this an felt the urge to do a pedant post.
An unsigned/signed type is NOT a std_logic_vector. They are their own types. Because they are all arrays of std_logic, they are "similar" type and you can do simple type conversions between them, but an unsigned is NOT a std_logic_vector. it can also be treated as an unsigned integer (which is what it is intended as). it is the non-standard std_logic_unsigned library that allows you to interpret std_logic_vectors as unsigned integers.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Thanks.
This is very helpfull
 

Sorry - saw this an felt the urge to do a pedant post.
An unsigned/signed type is NOT a std_logic_vector. They are their own types. Because they are all arrays of std_logic, they are "similar" type and you can do simple type conversions between them, but an unsigned is NOT a std_logic_vector. it can also be treated as an unsigned integer (which is what it is intended as). it is the non-standard std_logic_unsigned library that allows you to interpret std_logic_vectors as unsigned integers.


It may be formally incorrect to say that "unsigned is a std_logic_vector interpreted as an unsigned number", but it will help to take the right decisions.

The type definitions for std_logic_vector, unsigned and signed are identical. For synthesis, this means that there is no reason to avoid unsigned/signed (and numeric_std).

I attach a document that I think is very useful when using unsigned/signed etc. in VHDL
 

Attachments

  • numeric_us_1785.pdf
    107.2 KB · Views: 64

it wont work as it is, because it is ambiguous - the compile wont know if the string is a signed or unsigned type. You will need to either convert the integer or qualify the string.
Comparing an integer against unsigned or signed works without additional prerequisites, at least in Altera Quartus and ModelSim. I'm using it since ever.
 

yes, there are no pre-requesits when the type is already known. But "0000" could be a signed or unsigned, and "=" exists for both.

So with the expression:

if a + b = "0000" then...

where a and b are integers, You will get an error because the "=" functions exists for comparing integers to signed and unsigned types, and it is not clear to the compiler whether the "0000" is a signed or unsigned type. Hence the need to convert the integer or qualify the string.
 

You're right for the "0000" bit vector constant, which is neither signed nor unsigned. My example was referring to signed or unsigned signals, as said. I didn't understand comparing a sum of two constants with a third constant as real coding problem. Once more a problem of discussing code snippets...
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top