Jump to content
Lynn Garibaldi

Seeking Feedback on Datatypes

Recommended Posts

The SystemC Synthesis Working Group is very active and is currently addressing several issues, including:

  1. Defining more clearly what elaboration behavior is supported for synthesis. More specifically, the dynamic module instantiation, binding, and naming, (e.g., using loops during elaboration).
  2. Considering what array/vector container to support.
  3. Looking at the use of C++ 11 attributes for synthesis directives.
  4. Analyzing the inclusion of AC datatypes as a numerical library.

Our goal over the next 12 months is to see some convergence on a second version of the SystemC Synthesis standard with the issues resolved and based on more updated versions of the C++ standard such as C++ 11, 14, and possibly 17. At SystemC Evolution Day last October there were some datatype proposals presented, and we’d like to get more feedback from the community on them. Suggestions and input are welcome in this forum. We look forward to hearing from you.

Share this post


Link to post
Share on other sites

Some thoughts on these topics:

On 9/11/2018 at 12:19 PM, Lynn Garibaldi said:

1. Defining more clearly what elaboration behavior is supported for synthesis. More specifically, the dynamic module instantiation, binding, and naming, (e.g., using loops during elaboration).

During elaboration any C++ should be supported, including standard library. Language/library restrictions should only be imposed on process bodies (SC_THREADs and SC_METHODs). Otherwise SystemC synthesis would not be competitive vs languages focused on structure generation. Some design teams are already switching from SystemC to Chisel due to limitations in SystemC tools.

Quote

2. Considering what array/vector container to support.

std::array can be supported, but adds little value compared to C-style arrays.

sc_vector should be supported. But unfortunately it only supports sc_object types. So I can't for example create sc_vector<sc_int<32>> to model RAM with elaboration-time defined size.

std::vector allows expansion during simulation, that won't be synthesizable.

I think it would be a good idea to extend sc_vector with non-sc_object types support. Also more flexible API can be added, like emplace_back(...) for elaboration-time programming.

Quote

3. Looking at the use of C++ 11 attributes for synthesis directives.

Attributes can't be used with template-based compile-time programming and elaboration-time programming. Macros will be the only way to program with attributes. That is bad.

Instead, why not to to standardize a set of functions to pass synthesis directives?

Quote

4. Analyzing the inclusion of AC datatypes as a numerical library.

As usual, there is a compromise between simulation performance and flexibility of usage. I looked through proposals, and I think it would be nice to have both AC datatypes and improvement to existing bigint SystemC datatypes.

From flexibility perspective, sc_unsigned and sc_signed are ideal, because they can be used both with template-based meta-programming and  elaboration-time programming. So we have the same structural programming flexibility as in Chisel or MyHDL.

AC datatypes are less flexible, but more efficient. 

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

×