-1

I am using Synopsis VCS compiler. My testbench is coded in UVM. I have a set of C routines that perform some standalone functions. I am calling these C routines through DPI imports in the UVM environment.

Here is the code snippet in a simple way,

uint64_t blah, var1, blah_1;
var1 = UVM_class::C_function_1(uint64_t blah);
blah_1 = UVM_class::C_function_2(uint64_t var1);

if(blah_1 != blah) assert(0);
# 
uint64_t C_function_1(uint64_t blah)
{
..... 
.....

uint64_t x = function1(...);

return x;
}
# 
uint64_t function1(...)
{
uint64_t y;
calculate some stuff
return y;
}

Here is the issue: If I run this as a part of regression, about 10000 times it works perfect.

At the 10001th time, this is what happens.

function1 retruns the correct value and I see that when I print y. However, when I print x inside C_function_1, x has something like 0xffffff_fffff_y. That is value of y is present, but there is some garbage attached to it. This messes up subsequent calculations that involve x.

I read a lot regarding stack getting messed up and made sure I malloc'd and free'd all pointers that are arguments to various functions.

I also tried running the C portion as standalone and there is no error and the regression is clean.

The only issue is when I run the UVM test which calls the C regression routine.

I have spent a lot of time debugging this to no avail.

Anybody any suggestions?

nguthrie
  • 2,615
  • 6
  • 26
  • 43
user3662733
  • 51
  • 3
  • is it possible to post the entire code of the function that is failing? – M.M May 21 '14 at 22:31
  • 1
    It's impossible to try and resolve this issue with `blah` as sample variables and code blocks that contain `...` as the majority of content. If you want help with a code-related issue, you need to post *real* code. Saying "I promise I looked at it and it doesn't do anything wrong, but it still fails with this problem" is meaningless, as we can't see what you looked at or what you might have missed from your fictional code. – Ken White May 21 '14 at 23:08
  • Are you calling these functions from tasks? Perhaps you need to use semaphores to coordinate access to the dpi functions. – Stephan May 22 '14 at 15:01

1 Answers1

0

I am the poster of the question and I tried three things as far as restructuring my code was concerned and I do not see this behaviour anymore :)

1) Made certain key variables global. Hence, they have no business with the C stack and can be saved from stack issues

2) Had a number of functions calling other functions to do basic one liner stuff. Reduced the number of functions and hence less chances for the stack to get messed up. This worked for me as I mentioned my functions were doing one liner stuff...combined my four functions each with 15 variables into one single functon with 4 lines.

3) Third and I think the most important thing:

I had statement like this in my for loops

int a = func();

So, this means a local variable is being created everytime the loop is traversed...the stack will grow unnecessirily.

changed it to :

int a;

inside the loop: a =func();

now, the stack grows just once and this could also save the stack from getting messed up.

These are the steps I took and I do not see this behaviour anymore.

user3662733
  • 51
  • 3