Jump to content
csr18

Implicit conversion for sc_bitref and sc_bitref_r in SystemC-2.3.1

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

This may confuse users. Especially B). 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

Share this post


Link to post
Share on other sites

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

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

B) 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 B). 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 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×