What's going on with biguint ?

[DavidC]

Hi,

Here is a short example, with two implementations of the same thing, where bit patterns are being manipulated.

One is based on sc_uint<>, the other on sc_biguint<>. I believe that both should be equivalent but it does not seem to be the case.

 

#include <systemc.h>

int sc_main (int argc, char* argv[])
{
  cout << std::hex;

  sc_uint<32> Reg0 = 0x00001248;

  Reg0 = (Reg0 << 16) | (((Reg0 >> 15) ^ (Reg0 >> 12)) & ((1 << 16) - 1));   cout << "Reg0 = " << Reg0 << " - Expect 12480001" << endl;
  Reg0 = (Reg0 << 16) | (((Reg0 >> 15) ^ (Reg0 >> 12)) & ((1 << 16) - 1));   cout << "Reg0 = " << Reg0 << " - Expect 00010010" << endl;
  
  sc_biguint<32> Reg1 = 0x00001248;

  Reg1 = ( Reg1.range(15, 0), (Reg1.range(30, 15) ^ Reg1.range(27, 12)) );   cout << "Reg1 = " << Reg1 << " - Expect 12480001" << endl;
  Reg1 = ( Reg1.range(15, 0), (Reg1.range(30, 15) ^ Reg1.range(27, 12)) );   cout << "Reg1 = " << Reg1 << " - Expect 00010010" << endl;
  
  return 0;
}

 

The sc_uint-based implementation produces the correct answer, but not the sc_biguint-based one.

        SystemC 2.3.3-Accellera --- Nov 11 2021 11:49:06
        Copyright (c) 1996-2018 by all Contributors,
        ALL RIGHTS RESERVED
Reg0 = 012480001 - Expect 12480001
Reg0 = 000010010 - Expect 00010010
Reg1 = 012480001 - Expect 12480001
Reg1 = 000020010 - Expect 00010010

 

Am I making a very silly mistake somewhere ? Are there subtle rules for the biguint range and concatenation operators that I'm not aware of and that would explain this behaviour ?

Thanks !

David

[DavidC]

I suppose my initial example was possibly a bit too complicated, so how about this very simple one:

int sc_main (int argc, char* argv[])
{
  sc_biguint<32> Reg1;

  Reg1 = 0x00001248;
  cout << "XOR pattern length = " << (Reg1.range(30, 15) ^ Reg1.range(27, 12)).length() << endl;
    
  Reg1 = 0x12480001;
  cout << "XOR pattern length = " << (Reg1.range(30, 15) ^ Reg1.range(27, 12)).length() << endl;
    
  return 0;
}

 My expectation is that the "XOR pattern length" would be 15 bits (isn't it reasonable, with bit-wise logical combination of two 15-bit patterns ?)

Yet what I'm seeing is a bit different...

        SystemC 2.3.3-Accellera --- Nov 11 2021 11:49:06
        Copyright (c) 1996-2018 by all Contributors,
        ALL RIGHTS RESERVED
XOR pattern length = 10
XOR pattern length = 11

Is this a bug ? or is this perfectly expected based on the known behavior of SystemC types ? In the latter case, what is the rationale that justifies this intended behavior ?

[DavidC]

Any comments from the Accellera folks ?

[Bas Arts]

I think the range includes both left and right, so I'd expect the pattern length to be (left - right + 1) = (0x)10. I don't know why the second XOR pattern length is (0x)11, though.