1
\$\begingroup\$

Does VHDL specify how intermediate calculations are handled? For example, I have the following constant defined in one of my entities.

constant MAX_ADDR : integer := (1024*1024*1024*8)/64;

In Aldec's ACTIVE-HDL simulator the constant correctly evaluates to 134,217,728. On the other hand, in Vivado the (1024*1024*1024*8) portion of the calculation appears to overflow the 32bit integer type prior to the division by 64, leading to incorrect synthesis (and several hours of builds, debugging, and frustration).

\$\endgroup\$
4
  • 1
    \$\begingroup\$ I afraid VHDL is not standardized as strictly as, say, C. So the compilers are a bit willy-nilly about how to do some things... \$\endgroup\$
    – Eugene Sh.
    Commented Jul 6, 2018 at 14:35
  • \$\begingroup\$ Make constants constant by plugging in the value not a calculation \$\endgroup\$
    – Voltage Spike ♦
    Commented Jul 6, 2018 at 15:28
  • \$\begingroup\$ Is that Vivado 32-bit or 64-bit? Or is Vivado only in 64-bit? I still work with Webpack, which is available in 32-bit and 64-bit versions. \$\endgroup\$
    – chthon
    Commented Jul 7, 2018 at 8:22
  • \$\begingroup\$ Btw., you should also re-factor your value correct. It's easy to see that 8/64 is 1/8, and that 1024/8 leads to 128, which means that you can still express your constant as 1024*1024*128. \$\endgroup\$
    – chthon
    Commented Jul 7, 2018 at 8:23

2 Answers 2

Reset to default
3
\$\begingroup\$

VHDL only guarantees a minimum of 32 bits to represent a (signed) integer. Trying to cram a 34-bit unsigned value into it, even as an intermediate value, is just asking for trouble.

You were careless and got bit. Get over it.

\$\endgroup\$
2
  • \$\begingroup\$ I guess the focus of the question was really on how preprocessor operations work. If I had defined the constant as a 34 bit unsigned type would the calculation be guaranteed to evaluate correctly? Also, I honestly figured the standard would define this as an error and was trying to figure out if a bug report was needed. Totally over it. \$\endgroup\$
    – ks0ze
    Commented Jul 7, 2018 at 15:29
  • \$\begingroup\$ Yes, using an appropriate type would have worked. \$\endgroup\$
    – Dave Tweed
    Commented Jul 7, 2018 at 15:34
2
\$\begingroup\$

I guess Dave meant that 32 bits is maximum to represent an integer. Instead of integer you can try signed or unsigned. Or, if you are sure about accuracy and that value would not be greater than 2^31-1, you can put division first and then multiplication and it would be compiled properly:

constant MAX_ADDR : integer :=(1024/64*1024*1024*8);
\$\endgroup\$
7
  • 1
    \$\begingroup\$ No, it's minimum. There is no point to guarantee maximum. \$\endgroup\$
    – Eugene Sh.
    Commented Jul 6, 2018 at 16:39
  • \$\begingroup\$ Well, if you create integer signal you can't assign it values more than 32 bits length. I mean, you can, but result would be zero because integer is limited up to 32 bits length. "The only predefined integer type is the type INTEGER. The range of INTEGER is implementation dependent, but it is guaranteed to include the range -2147483647 to +2147483647" - cited from ieee standard vhdl \$\endgroup\$
    – Daniil Smirnov
    Commented Jul 6, 2018 at 16:52
  • \$\begingroup\$ Right. To include this range it has to be minimum 32-bit wide. \$\endgroup\$
    – Eugene Sh.
    Commented Jul 6, 2018 at 16:55
  • \$\begingroup\$ How it can be minimum if 32 bits is maximum wide? If i'll create integer signal and specify renge from 0 to 15 it will be total 4 bits wide. You can check in in RTL Viewer \$\endgroup\$
    – Daniil Smirnov
    Commented Jul 6, 2018 at 16:59
  • 1
    \$\begingroup\$ In order a type to include a range 0 to 15, it has to be at least 4 bits wide. If it will be 5 bits wide, it will also include 0 to 15. But if it will be 3 bits wide, there is no way it will include 0 to 15. Which makes it minimum 4 bit wide. And it is not related to RTL, but to a formal definition. \$\endgroup\$
    – Eugene Sh.
    Commented Jul 6, 2018 at 17:01

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.