0

Consider the following SystemC code:

#include <iostream>
#include "systemc.h"

using namespace std;

int
sc_main(int argc, char* argv[])
{
    sc_bv<3> foo;   
    operand_0 = "0d6";
    cout << foo.to_long() << endl; // prints -2
    return EXIT_SUCCESS;
}

This prints out -2 rather than 6 as I would have expected. The apparent reason for doing so would be that to_long() interprets the bit-vector 0b110 as signed. However, in IEEE Std 1666-2011, it says in Section 7.2.9 referring to integer conversion functions such as to_long():

These member functions shall interpret the bits within a SystemC integer, 
fixed-point type or vector, or any part-select or concatenation thereof, 
as representing an unsigned binary value, with the exception of signed
integers and signed fixed-point types.

Do I misunderstand something or is the SystemC implementation from Accellera not adhering to the standard in this aspect?

AndresM
  • 1,293
  • 10
  • 19
Holger Watt
  • 175
  • 8

1 Answers1

2

I think you are correct, there does seems to be a discrepancy between the SystemC LRM (IEEE Std 1666-2011) and the implementation.

If you want foo to be interpreted as an unsigned value, you must use to_ulong():

#include <iostream>
#include <systemc>

using namespace std;

int sc_main(int argc, char* argv[]) {
    sc_bv<3> foo("0d6");
    cout << foo.to_long() << endl; // prints -2
    cout << foo.to_ulong() << endl; // prints 6
    return EXIT_SUCCESS;
}
AndresM
  • 1,293
  • 10
  • 19
DarrylLawson
  • 732
  • 3
  • 9
  • Hi Darryl, Thanks for helping. I do not understand how this proviso applies: In the snippet, foo is a bit vector and not a signed integer or signed fixed-point type. Why do you assume that sc_bv can be considered a signed integer or signed fixed-point type? – Holger Watt Jun 08 '15 at 15:33
  • I apologize, I think you're correct: there is a discrepancy. I didn't appreciate the subtleties of what that paragraph is saying. For me, given that there is a to_uint(), it seems intuitive for to_int() to treat all values, including for a sc_bv type, as a signed value. But that is beside the point: that does not seem to be what the LRM is saying. I'll amend my answer. – DarrylLawson Jun 08 '15 at 23:23
  • Yes, with respect to intuition, I could not agree with you more. Still, I feel following the standard here is rather important from a practical point of view. Currently, I am in the situation using both an industrial tool that seem to behave conformant to the standard in this aspect and the simulation using the Accellera libraries that does not and the discrepancy is rather annoying. I'll see if I find a way to submit this as a bug to the authors of the Accellera libraries. Thanks again for your help. – Holger Watt Jun 09 '15 at 08:52