Home > Community > Blogs > System Design and Verification > a systemc virtual platform overflowing the stack just before dac
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

A SystemC Virtual Platform Overflowing the Stack -- Just Before DAC

Comments(5)Filed under: SystemC, DAC, System Design and Verification, virtual platforms, virtual prototypes, Virtual System Platform, demo, stack overflow

Thanks to all who stopped by the Cadence booth to see and talk about the Cadence Virtual System Platform at DAC. I spent most of the week in meetings and giving presentations and demos so I don't have any insight into the virtual platform related events from the conference. Instead of writing a general report about how important virtual platforms are or how many people came to see the recently announced Virtual System Platform, I will use my DAC wrap-up for something more educational, a DAC demo story.

I have been going to DAC as an EDA vendor for about 15 years. Things have changed dramatically over that time in how we prepare demos and execute them on the exhibit floor and in the demo suites. In the early days all demos where run on Sun workstations; most of the time these were provided by Sun for the show. This meant we got to DAC on Sunday to find a blank machine ready to be prepared with the demos. These were the days when a C compiler wasn't even part of a standard OS installation.

Of course, there were no internet connections for loading the demo data. I think at first there were only SCSI tape drives and we brought the demos on a tape. Later there were CD-ROM drives, but a CD writer was not always easy to find. There was always the story about a missing SCSI terminator stopping somebody from loading any demo data and lot of scrounging around to find all the parts and load the demo data. If some files were missing or some demo data was left behind there wasn't much that could be done about it. I'm sure there are some pretty crazy stories out there about pulling all-nighters to get the DAC demos working.

Things are much different today as most demos can be run on laptops and there is Internet access everywhere to get any missing data. We even ran some demos remotely on machines inside Cadence using an Internet connection. I'm sure much less sleep is lost on the eve of DAC -- a good thing at a time when everybody is trying to do more with less.

Even though all of the demo prep has become much easier, I bet a lot of last minute work still goes into getting the latest and greatest software releases and demo designs ready to show at DAC. You can imagine this is the case for the Virtual System Platform as a relatively new product. While the majority of our demos were running fine long before DAC, we did have one that was brand new, but it was very impressive so I wanted to have it working at the show.

On the eve of DAC, the virtual platform simulation was crashing with a message about a SystemC stack overflow as shown in the screenshot below. This occurred after about 25 simulated seconds.

 

 

 

Since other virtual platform creators may encounter the same situation I thought it would be useful to provide some insight into what it means and what can be done about it. A quick search of the Cadence bug database revealed that stack overflow has been encountered by users and I would anticipate this may occur even more frequently as virtual platforms increase the usage of SystemC.

To get some answers I turned to Bishnupriya Bhattacharya, an R&D Architect and an expert in the Cadence SystemC simulation kernel. She has been active in the SystemC working groups and a leading contributor to the SystemC standards process for a number of years.

I asked Bishnupriya a few questions to provide more insight into the background of SystemC stack overflow.

Q: What is a stack overflow?

A: Stack overflow can happen in SystemC designs due to a number of factors. The most common cause is if local variables declared in a SystemC thread take up a lot of stack space, that is, large-sized arrays. Other factors can be a very deep function call chain inside a thread process, or in the extreme case a recursive call chain.

The simple example below demonstrates how the array 'big_array' declared as a local variable in the SystemC thread process 'run' will cause a stack overflow.

#include "systemc.h"

#define ARRAY_SIZE 100000

SC_MODULE(mod) {
public:
  SC_CTOR(mod) {
    SC_THREAD(run);
   }
   void run() {
     int big_array[ARRAY_SIZE];
     for (int i = 0; i < ARRAY_SIZE; i++) {
       big_array[i] = 0;
     }
   }
};
 
int sc_main(int, char**) {
  mod m("mod");
  sc_start(10, SC_NS);
  return 0;
}  
 
 

Q: What's the best way to correct a stack overflow?

A: The simplest and quickest way to correct the crash is to increase the stack size of all SystemC threads. This can be done using the command line option ‘-SC_THREAD_STACKSIZE <size>'.

 

Q: Are there other ways to fix a stack overflow?

A: Other ways of fixing a stack overflow involve code changes in the SystemC design. One technique is to avoid using a large stack inside a thread process -- for example, move any declaration of large sized variables from the stack to the heap, or dynamically allocate the variable using ‘new' instead of allocating it on the stack. The other technique is to use the SystemC API set_stack_size() to increase the stack size of the particular thread that needs a large stack after declaring it in the parent module's constructor. This is shown in the example below.

 

#include "systemc.h"

#define ARRAY_SIZE 100000

SC_MODULE(mod) {
public:
  SC_CTOR(mod) {
    SC_THREAD(run);
    set_stack_size(0x64000);
  }
  void run() {
    int big_array[ARRAY_SIZE];
    for (int i = 0; i < ARRAY_SIZE; i++) {
      big_array[i] = 0;
    }
  }
};

 

int sc_main(int, char**) {
  mod m("mod");
  sc_start(10, SC_NS);
  return 0;   
}
 

Although these techniques are more intrusive and more time-consuming, these are superior than using the command line option ‘-SC_THREAD_STACK_SIZE', as the latter will increase the stack size of every thread in the design, thus blowing up its memory footprint, whereas for the former, only the thread that needs a larger stack will be allocated more memory -- or better still there won't be any need of a larger stack at all.

 

Q: What is the default stack size for each SystemC thread?

A: The default stack size of each SystemC thread is 0x16000 or 64 KB. The default stack size of sc_main is 4 MB. 

 

Q: Does the IEEE SystemC standard have anything to say about the stack usage of threads?

A: IEEE p1666 specifies the set_stack_size() API to change the stack size of a thread process. However, it does not mention the default stack size of a thread process since that is an implementation detail. The same default thread stack size of 64 KB is used between the OSCI proof-of-concept simulator and the Cadence simulator. 

 

Q: Do users ever report simulator bugs on situations like stack overflow?

A: Yes, users do report simulator bugs in stack overflow situations. Based on increasing awareness through documentation and training, usually we are able to turn these around pretty quickly.

 

Q: Any other words of advice to avoid stack overflow crashes?

A: One thing to keep in mind as a good programming practice is not to declare large sized local variables inside a thread process -- either these can be declared as module member fields (if appropriate) or should be allocated on the heap, instead of the stack. Also, recursion should be strictly avoided inside a thread process, as that will quickly blow up the stack.   

 

The good news is that the ‘-SC_THREAD_STACKSIZE <size>' was able to easily fix the problem and the demo was a great success at DAC!

Hopefully this was more interesting for the virtual platform creators in the audience than a marketing discussion about how our open SystemC approach is the right one, or about how our tools are very capable for virtual platforms developers and users. It might even save somebody a call to Cadence to report something wrong with the simulator.

Jason Andrews

 

Comments(5)

By Wataru Yamamoto on June 14, 2011
Useful and practical !!!
Thank you very much :-)

By Dan on October 28, 2011
Great post,  that saved me last night when it would have been too late to call support!

By Christian Sauer on May 8, 2012
Note the typo in the conversion of hex sizes into decimal kB values:
0x10000  = 64 kB, 0x20000 = 128 kB, 0x40000 = 256kB.

By Christian Sauer on May 8, 2012
For some simulation hosts, we did observe an additional dependency for the stack size.
That is the alignment with a host's page size. In such cases, the stack size must be a mutliple of the page size.
So, if the page size is, e.g., 64 or 128 kB, than 0x40000 would be the minimum stack size (observed on a vbox/CentOS 64bit system).
This misalignment error manifested at thread destruction time assertion: sc_cor_qt.cpp:XXX: virtual void sc_core::sc_cor_qt::stack_protect(bool): Assertion `ret == 0' failed.

By Rafael Zuralski on September 11, 2013
Thank you Jason and Christian,
adding '-SC_THREAD_STACKSIZE 0x80000' to my irun calls solved the mentioned assertion during the SystemC language fundametal training. This information should be added to the lab documentations.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.