Jump to content

Interpretation of sc_dt::sc_lv<32> L("0b1........................")

Bas Arts

Recommended Posts

I ran into a difference between simulators. See the following code:

#include <iostream>
#include <systemc>

int sc_main(int argc, char* argv[]) {
    sc_dt::sc_lv<32> L("0b11010000000000000000000011000100");
    std::cout << std::hex << "to_int64:      0x" << L.to_int64() << std::endl;

    return 0;

Running this in the Accellera PoC and a certain commercial simulator shows the following output:

to_int64:      0xffffffffd00000c4

However, a different commercial simulator shows the following:

to_int64:      0xd00000c4

In the Accellera PoC, this is caused by the `to_anything_signed` method in `sc_proxy.h` which checks the MSB for 0. I wonder whether the PoC is free to make this implementation choice? Any thoughts on this?

Link to comment
Share on other sites

The corresponding clause in 1666-2011 is 7.2.9 Integer conversion, quoting from there:


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.

I would read this as: logic vectors shall not be sign-extended.

Link to comment
Share on other sites

Thanks Philipp. Interestingly, 7.3 String literals states that (emphasis mine)


The prefix shall be followed by an unsigned integer value, except in
the cases of the binary, octal, and hexadecimal formats, where the prefix shall be followed by a two’s
complement value
expressed as a binary, octal, or hexadecimal integer, respectively.

As such, I'd assume that

sc_dt::sc_lv<32> L("0b11010000000000000000000011000100");

represents a negative value. Apparently, to_int64() also interprets it in this way given the leading f's in the output.

Link to comment
Share on other sites

I would think that 7.3 only applies to the conversion to a SystemC datatype. If the literal would be smaller than the target type, the sign extension applies, quoting the very next sentence from the section you quoted:


An implementation shall sign-extend any integer string literal used to set the value of an object having a longer word length.

... unless you omit the prefix:


A bit-pattern string (containing bit or logic character values with no prefix) may be assigned to a vector. If the number of characters in the bit-pattern string is less than the vector word length, the string shall be zero extended at its left-hand side to the vector word length. 

In your example, you pass in a literal with the matching length of the destination type and there should not be any extension anyway.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...