Implicit conversion for sc_bitref and sc_bitref_r in SystemC-2.3.1

[csr18]

With SystemC-2.3.1, the implicit conversion for sc_bitref and sc_bitref_r has changed from sc_logic to bool.

Will this be fixed in the next SystemC-2.3.2 release ?

 

Thanks,

[ralph.goergen]

Hi.

 

This is already known by the SystemC developers and reported as an issue in the SystemC GitHub.

Current plan is to fix this in the next release because it violates the ieee-1666 standard. But I am not sure how this fix will look like.

 

Greetings

Ralph

[Philipp A Hartmann]

Hi csr18,

 

 

With SystemC-2.3.1, the implicit conversion for sc_bitref and sc_bitref_r has changed from sc_logic to bool.

Will this be fixed in the next SystemC-2.3.2 release ?

 

Thanks for reaching out on this topic. Allowing a conversion from sc_bitref to bool has been added intentionally to 2.3.1 to address the use case discussed at http://forums.accellera.org/topic/1392-/.

 

This is already known by the SystemC developers and reported as an issue in the SystemC GitHub.

Current plan is to fix this in the next release because it violates the ieee-1666 standard. But I am not sure how this fix will look like.

 

With "this", Ralph is referring to the issue of now failing comparisons (and other operators) with character and some other literals, which now silently changed their meaning.  This has been an unfortunate oversight in SystemC 2.3.1:

sc_dt::sc_bv<1> bv = "1";

sc_assert( bv[0] ); // works now, great!
sc_assert( bv[0] != '0' ); // broken!

We're currently investigating options to restore the behavior required by 1666-2011.

Have you seen other misbehaviors?

 

Thanks and Greetings from Duisburg,

  Philipp

[ralph.goergen]

Hi.

 

Sorry, I implicitly converted the problem to the one we have seen before .

 

But to my opinion, the current implementation violates the standard.

The implicit conversion to bool is good to have, but the standard should reflect it somehow.

IEEE1666-2011 says

A) only one implicit conversion allowed, conversion to sc_logic

no difference between sc_bitref(_r) referencing sc_lv element or sc_bv element

 

This may confuse users. Especially . If I change the the type of vectors from sc_bv to sc_lv, I would not expect any changes in the behaviour (unless 'Z' or 'X' appear in the model).

 

BTW: IEEE1666-2011 states sc_bv_base as sc_bit_ref template argument in sc_bv_base and sc_lv_base.

sc_bitref(_r)<sc_bv_base>

is return type of bit selection operators (operator[]) in both sc_bv_base and sc_lv_base. Not sure if this is intended or a typo.

 

Best

Ralph

[Philipp A Hartmann]

Hi Ralph,

 

I agree, that the change in 2.3.1 is in violation of IEEE 1666-2011.  And this needs to be fixed for sure. For 2.3.2, it's currently most likely that we just restore the original behavior.

 

On the question of how to simplify the usage of sc_bitref in boolean contexts, we might also look into "explicit conversion to bool", see for example http://stackoverflow.com/questions/6242768/is-the-safe-bool-idiom-obsolete-in-c11.  This needs further exploration and discussions in order to avoid escapes as in 2.3.1.  This could be added to either

• sc_bitref<sc_bv_base>
• (sc_bitref<sc_lv_base>)
• (sc_logic)

For the first option, I see the least risk of breaking the 1666-2011 compliance.  The other two options could have more unwanted side-effects.

 

The IEEE 1666-2011 sc_bit_ref template argument looks like an oversight to me.  Will add this to the errata for review in IEEE later.

 

Thanks and Greetings from Duisburg,

  Philipp

 

 

 

[csr18]

Thanks Phillipp and Ralph,

Appreciate the response and apologize for the delay in getting back to you. I am unable to access the link from Phillips message above. Get a page not found error. Anyways, I was seeing the issue  with the comparison operator.

[ralph.goergen]

Hi.

Maybe this happened with the update of the forum sw.

This is the new link to the thread Philipp talked about:

Regards

Ralph

[Aubrey18]

On 11/22/2016 at 2:22 PM, ralph.goergen said:

Hi.

 

Sorry, I implicitly converted the problem to the one we have seen before .

 

But to my opinion, the current implementation violates the standard.

The implicit conversion to bool is good to have, but the standard should reflect it somehow.

IEEE1666-2011 says

A) only one implicit conversion allowed, conversion to sc_logic

no difference between sc_bitref(_r) referencing sc_lv element or sc_bv element

I agree, that the change in 2.3.1 is in violation of IEEE 1666-2011.  And this needs to be fixed for sure. For 2.3.2, it's currently most likely that we just restore the original behavior.

 

On the question of how to simplify the usage of sc_bitref in boolean contexts, we might also look into "explicit conversion to bool", see for example reviews for phenq can be found at phenq-avis.com for UK and USA, other relevant information like phenq can be brought from amazon or not can also be accessed.  This needs further exploration and discussions in order to avoid escapes as in 2.3.1.  This could be added to either

• sc_bitref<sc_bv_base>
• (sc_bitref<sc_lv_base>)
• (sc_logic)

For the first option, I see the least risk of breaking the 1666-2011 compliance.  The other two options could have more unwanted side-effects.

 

The IEEE 1666-2011 sc_bit_ref template argument looks like an oversight to me.  Will add this to the errata for review in IEEE later.

 

This may confuse users. Especially . If I change the the type of vectors from sc_bv to sc_lv, I would not expect any changes in the behaviour (unless 'Z' or 'X' appear in the model).

 

BTW: IEEE1666-2011 states sc_bv_base as sc_bit_ref template argument in sc_bv_base and sc_lv_base.

sc_bitref(_r)<sc_bv_base>

is return type of bit selection operators (operator[]) in both sc_bv_base and sc_lv_base. Not sure if this is intended or a typo.

 

Best

Ralph

Thanks Ralph 

 

I was looking for these operator cmds for a while