Pointers in C and C++

1) How to declare a pointer?
A: Imagine that we have an int called i. Its address could be represented by the symbol &i. If the pointer is to be stored as a variable, it should be stored like this.
int *pi = &i;

Two step process will be
int *pi;
pi = &i;

2) How this program is interpreted by the C compiler?
1:#include 2:int main()
3:{
4: float fl=3.14;
5: std::cout <<>grabs the address reserved for fl.
b) The contents stored at that address are retrieved.

To generalize, whenever any variable is accessed, the above two distinct steps occur to retrieve the contents of the variable.

3) Can we seperate the above two steps in C?
A: Two operators are provided that, when used, cause these two steps to occur separately.
operator meaning example
& do only step 1 on a variable &fl
* do step 2 on a number(address) *some_num
Try this code to see what prints out:
1: #include
2: int main()
3: {
4: float fl=3.14;
5: printf("fl's address=%u\n", (unsigned int) &fl);
6: return 0;
7: }
On line (5) of the example, The & operator is being used on fl. On line (5), only step 1 is being performed on a variable:
1. The program finds and grabs the address reserved for fl...
It is fl's address that is printed to the screen. If the & operator had not been placed in front of fl, then step 2 would have occurred as well, and 3.14 would have been printed to the screen.

Now let's test the other operator, the * operator that retrieves the contents stored at an address:
1: #include
2: int main()
3: {
4: float fl=3.14;
5: unsigned int addr=(unsigned int) &fl;
6: printf("fl's address=%u\n", addr);
7: printf("addr's contents=%.2f\n", * (float*) addr);
8: return 0;
9: }

In line (7), step 2 has been performed on a number:
2. The contents stored at that address [addr] are retrieved.

4) What are the uses of pointers?
A: 1) First, they are used to create dynamic data structures: data structures built up from blocks of memory allocated from the heap at run-time. This is the only visible way that Pascal uses pointers.

2) Second, C uses pointers to handle variable parameters passed to functions.
Normally functions in C and C++ are used by pass by value. Value of the variables passed through the function cannot be modified from inside the function. Any modification inside the function doesn't effect the variable that is passed through the function.

If we want the modifications inside the funtion to reflect in the main program we call the funtion with variables by pass by reference. This pass by value behavior and change values passed into functions can be done by using the & and * operators

1: #include
2: void somefunc(unsigned int fptr)
3: {
4: *(float*)fptr=99.9;
5: }
6:
7: int main()
8: {
9: float fl=3.14;
10: unsigned int addr=(unsigned int) &fl;
11: somefunc(addr);
12: printf("%.2f\n", fl);
13: return 0;
14: }

Quite simply, the two steps that normally occur when accessing a variable are being separated to allow us to change the variable's value in a different function.

1: The floating point variable fl is created at line (9) and given the value 3.14
2: The & operator is used on fl at line (10) (do only step 1, get the address). The address is stored in the integer variable addr.
3: The function somefunc is called at line (11) and fl's address is passed as an argument.
4: The function somefunc begins at line (2), fptr is created and fl's address is copied into fptr.
5: The * operator is used on fptr at line (4) -- do step 2, the contents stored in an address are retrieved.
6: The contents at this address are assigned the value 99.9.
7: The function finishes. Control returns to line (12).
8: The contents of fl are printed to the screen.

Putting it all together we have the following program.

1: #include
2: void somefunc(float* fptr)
3: {
4: *fptr=99.9;
5: }
6:
7: int main()
8: {
9: float fl=3.14;
10: float* addr = &fl;
11: somefunc(addr);
12: printf("%.2f\n", fl);
13: return 0;
14: }

C uses pointers in three main ways.

3) And third, pointers in C provide an alternative means of accessing information stored in arrays, which is especially valuable when you work with strings.

Gate Level Simulation

Even though a lot of STA and Formal verification tools exists in the industry now a days, one question still arises in the mind of many verification engineers. The question is "Why do we go for a gate level simulation?"

Some years ago, I felt that gate level simulation were not worth. In my view, if we do static timing analysis (STA) - Those who want to know more about STA, please click here- after post and route, and take the post routed net-list, Extracted Parasitics File and design timing constraints, then perform design timing checks at all corners - say setup, hold and clock gating check - then we should be OK, no need to perform the gate level simulation. Then I realized if our chip has system clocks that only talk to others in synchronous, works in a single mode of operation and the STA setup includes no constants and false paths, then we can cover everything through STA tools.

Gate level simulation represents a small slice of what should actually be tested for a tape-out. They offer a warm feeling that, what you are going to get back will actually work and secondly, they offer some confidence that your static timing constraints are correct.

But the common reason to go for a gate level simulations are as follows:

• To check if the reset release, initialization sequence and boot up sequences are proper.
• STA tools doesn't verify the asynchronous interfaces.
• Unintended dependencies on initial conditions can be found through GLS
• Good for verifying the functionality and timing of circuits and paths that are not covered by STA tools
• Design changes can lead to incorrect false path/multi cycle path in the design constraints.
• It gives an excellent feeling that the design is implemented correctly.

So before shipping a design to tape-out, we run a limited set of gate level simulations. Because there are some difficulties associated with this GLS, they are:

• Takes a lot of setting up and debugging
• Takes a huge amount of computing recourses ( CPU time and disk space for storing wave)
• RTL simulations alone take multiple days of run time even for a single regression. GLS takes 10* times.
• Generation of debug data (VCD, Debussy) is impossible with GLS

Some design teams use GLS only in a zero-delay, ideal clock mode to check that the design can come out of reset cleanly or that the test structures have been inserted properly. Other teams do fully back annotated simulation as a way to check that the static timing constraints have been set up correctly.

In all cases, getting a gate level simulation up and running is generally accompanied by a series of challenges so frustrating that they precipitate a shower of adjectives as caustic as those typically directed at your most unreliable internet service provider. There are many sources of trouble in gate level simulation. This series will look at examples of problems that can come from your library vendor, problems that come from the design, and problems that can come from synthesis. It will also look at some of the additional challenges that arise when running gate level simulation with back annotated SDF.

So In my opinion, the gate-level simulations are needed mainly to verify any environment and initialization issues.

What are the different thing that should be clean in Scan Sim?

1) Warning should be clean. We should know the reason for different types of warnings.
a) VDDO: This is taken care in the later part of the Chip flow. So we can ignore.
b) VSSO: This is taken care in the later part of the Chip flow. So we can ignore.
c) *afe: These warnings are deep inside the afe module. So we can ignore.
d) SDFNDP: SDF Negative Delay path. So we can ignore.
e) CSINFI: These are floating nets in the design. So we can ignore.
f) MACRDF: Redefine Warning. So we can ignore.
g) ILLPDX: Warning with v2k usage. So we can ignore.
h) RECOME: Just a recompile warning. So we can ignore.
i) LIBNOU: Library files given but not used warning. So we can ignore.
j) DLLOUT: The DLL will model a ¼ cycle delay so it should be fine to ignore the annotation warnings.
k) CUVWSP: Run script has nowarn for this warning. So we can ignore.
l) CUVWSB: Run script has nowarn for this warning. So we can ignore.

2) All the Timing violation should be reviewed. We should know the reason if we are waiving off.
a) We can ignore all the MEM (dual port ram) timing violations as we are bypassing the memories in the scan sim.
b) We should look into $setup, $hold, $setuphold, $recovery etc.