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 (download using links below), 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.

SystemC Datatypes Proposal

Algorithmic Datatypes Proposal

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

Hi,

I was previously involved with the Synthesis working group and supported efforts to facilitate a version of the SystemC data types that could be used for both simulation and synthesis.

I found the AC datatypes to be very useful for both and in my last project where I worked on HLS synthesis, we decided to continue to use the AC datatypes for simulation even though we decided to drop synthesis efforts.  The current SystemC types are difficult to use for simulation because of the lack of compile time sizing information and the very slow simulation times. The templated types allowed higher level templated functions to be written with predetermined and known sizes which were very important for system simulations. When complex arithmetic is needed these types become even more useful and also allow a framework where higher level simulation code can easily switch between floating point types and fixed point that is not possible with the current SystemC types.

Share this post


Link to post
Share on other sites
On 9/19/2018 at 3:23 PM, Roman Popov said:

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

Actually, it adds a lot of value. std::array can be passed by reference in a function call and the function can then determine the proper size of the array. This is much better than passing pointers, the C standard.

You can also copy an array, which should be synthesizable, which reduces coding and greatly improves readability.

It should be possible to implement some #include <algorithm>s on std::array too.

Also, you can have bounds checking for additional safety; although, that aspect is probably not synthesizable.

Additionally, constexpr should be quite helpful for the synthesis aspect.

Share this post


Link to post
Share on other sites
17 hours ago, Tony Kirke said:

Hi,

I was previously involved with the Synthesis working group and supported efforts to facilitate a version of the SystemC data types that could be used for both simulation and synthesis.

I found the AC datatypes to be very useful for both and in my last project where I worked on HLS synthesis, we decided to continue to use the AC datatypes for simulation even though we decided to drop synthesis efforts.  The current SystemC types are difficult to use for simulation because of the lack of compile time sizing information and the very slow simulation times. The templated types allowed higher level templated functions to be written with predetermined and known sizes which were very important for system simulations. When complex arithmetic is needed these types become even more useful and also allow a framework where higher level simulation code can easily switch between floating point types and fixed point that is not possible with the current SystemC types.

Same experience on our side. We are using AC types for CNN inference engine modeling.

The problem with sc_dt:: types is not only performance, but semantics also. For example sc_int and sc_uint types are limited to 64 bits in width. Probably it makes sense for software modeling, but for HLS this is not useful at all. And then you got this weird things happening with wrap-around on 64 bits:

sc_int<64> a, b;
sc_bigint<128> m;
m = a * b; // result is computed with 64 bits wraparound and then casted to 128 bits

 

16 hours ago, David Black said:

How are the AC types licensed?

Are there any copyrights or patents to be concerned with?

It's Apache license, https://github.com/hlslibs/ac_types/blob/master/LICENSE. The same as SystemC.  And it was proposed for synthesis on SystemC evolution day in 2017 http://www.accellera.org/images/activities/working-groups/S3._Datatypes.1.pdf .  So probably the only required thing is tool support from vendors other then Mentor.

Share this post


Link to post
Share on other sites
Quote

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

Some feedback on AC datatypes:

We have found AC datatypes to be an invaluable tool for large DSP ASIC designs. My experience is mostly on the simulation front where speed, bit- (but not necessarily cycle-) accuracy, and seamless integration with standard C++ code is important. AC datatypes provide all the relevant digital system design features (clipping/rounding/bit-slicing), as well as support for complex data types, with very little overhead. The ability to customize/expand AC datatype functionality via private headers (for simulation only) is another great benefit that minimizes the need for instrumentation code around HLS code during system simulations.

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

×