I was wondering if there's a special way to treat numeric literal constant in way similar to C language... i.e. in C we can do something like:

1LL //signed long long
1ULL //unsigned long long


is there something similar in VHDL that I'm not aware of?

  • \$\begingroup\$ Are you aware about real datatype? \$\endgroup\$
    – sharvil111
    Nov 19, 2015 at 9:33
  • \$\begingroup\$ is i'm aware of it, why? \$\endgroup\$ Nov 19, 2015 at 9:37
  • \$\begingroup\$ (my comment was "yes, i'm aware of it, why?") sorry. \$\endgroup\$ Nov 19, 2015 at 9:48
  • \$\begingroup\$ Oh, Sorry. I meant about integer datatype. It is a signed 32bit datatype. \$\endgroup\$
    – sharvil111
    Nov 19, 2015 at 10:21
  • \$\begingroup\$ You're speaking of datatype, my question is more focused on the semantic of the literal constant. I don't want to declare a signal or a constant signal (in such a case you can specify the datatype and the problem is solved), but when you use literal constant in an expression i was wondering if there's a shortcut to say "look this has to be treated as a signed or unsigned or whatever...". \$\endgroup\$ Nov 19, 2015 at 10:49

3 Answers 3


In VHDL, the constant declaration requires that the type is specified. The length is usually baked in to the type. For example

constant my_constant : unsigned(63 downto 0):= X"0000000000000001";

Whenever a signal is driven by a numeric constant, it's necessary to match the constant length with the signal length.

For example:

signal my_signal : unsigned(63 downto 0);
my_signal <= X"0000000000000001";

Since VHDL is strongly typed, if the literal length does not match the signal declaration, it will produce an error.

As jeff mentioned, it's also possible to use to_unsigned, as follows:

my_signal <= x + y + to_unsigned(1,my_signal'length);
  • 1
    \$\begingroup\$ Also, you could declare a function called ULL, so that you could have lines looking like my_64bit_signal <= ULL(1);. The function would simply make use of to_unsigned. \$\endgroup\$
    – scary_jeff
    Nov 19, 2015 at 9:44
  • \$\begingroup\$ i'm not entirely sure i'm understanding what you've written in your answer. The issue is actually something like this: if you have two unsigned signals x, y (with different bitwidth) and then declare the statement z <= x + y, the operator "+" is overloaded to perform a widening operation such that the sum makes sense, there's no type conversion in general, just a widening operation. My issue is, as example in general if you have a statement like z <= x + y + 1; the constant "1" i don't have entirely clear how it is treated, if it is treated like an integer, signed or not... \$\endgroup\$ Nov 19, 2015 at 9:53
  • \$\begingroup\$ Because some times i do arithmetic operations, but basically it complaints about the mismatching of the types involved, so basically if i could explicitly say something like z <= x + y + 1ULL, that would solve any problem provided the semantic i'm expecting from such statement. \$\endgroup\$ Nov 19, 2015 at 9:54
  • \$\begingroup\$ It's just a matter of specifying the value as a bit vector, for eg: z <= x + y + X"00000001". The constant must match the length of the signal on the left. \$\endgroup\$
    – stanri
    Nov 19, 2015 at 11:27
  • \$\begingroup\$ Using syntax like X"0001" shouldn't involve the prior knowledge of the bitwidth of the signals involved? \$\endgroup\$ Nov 20, 2015 at 9:01

All integer literals are signed 32-bit integers. So as of now VHDL has only one integer type, so no prefix or suffix is needed to distinguish the literals.

Of cause you can declare subtypes of integer:

subtype T_INT_8  is INTEGER range -128 to 127;
subtype T_UINT_8 is INTEGER range 0 to 255;

There is a discussion if VHDL should be extended to support 64-bit integers (and literals) or even bigger.

Discussions on the "P1076 Working Group" twiki:

  • \$\begingroup\$ surely an integer is just a special case of a signed bit vector? It's then a matter of creating a signed bit vector of 64 bits? \$\endgroup\$
    – stanri
    Nov 19, 2015 at 11:33
  • \$\begingroup\$ INTEGER is a scalar type, and while Paebbels claims they are 32 bit, they are not. They have a value range this is implementation dependent and is at least –2147483647 to 2147483647. INTEGER don't got bits. The discussion was to increase the minimum value range. (And this would allow conversion of a signed vector type (e.g. numeric_std or numeric_bit SIGNED) of length 63 (or 64 if the value ranges were unbalanced from 0). An unsigned conversion could have a maximum of 63 bits (NATURAL is a subtype of INTEGER). The consequence would be more storage for index values in an implementation. \$\endgroup\$
    – user8352
    Nov 19, 2015 at 20:10

An object with a type of signed or unsigned from IEEE packages numeric_bit and numeric_std is an array type comprised of sequentially ordered elements of an enumerated type.

An object of an array type with an enumerated element type can have a value provided by string literal, provided the string only contains character values of literals comprising the enumeration types element values.

In addition to string literals there are bit string literals which in -2008 with the addition of a length prefix integer value can trim or extend a string literal value derived from evaluating a based literal.

Additionally in -2008 there are signed and unsigned prefixes for base specifiers B, O and X, and an additional base specifier D.

Using -2008 syntax you might express 1ULL as 64X"1" and 1LL as 64SX"1" for a long comprised of a 32 bit value. There are aother based literal representations.

The applicable section of the -2008 standard 15.8 Bit string literals is worth reading as may be other references.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.