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.

DFT Concepts

The following are the DFT points.
1) Normally scan flops are inserted while doing Design synthesis. These scan flops are stitched while doing p&r (with magma).

2) The atpg tool(like tetramax) is used to generate test vectors for these scan flops.

3) There are basically three interfaces for scan flops for doing scan flops simulation.
a) SI (scan in)
b) SO (scan out)
c) Clock

4) What are scan chains?
A. In scan test mode, scan structure allows each sequential gates to be concentrated with other sequential gates and configured as a long shift register called scan chain.

5) There are two procedure to control and enable the scan simulation.
a) Scan Enable: In scan insertion majority of the flip flops are converted into scan flops with SI (1) , D(0) and SE(select) of the mux. The chip operates in shift mode if the SE is 1 and in capture mode it SE is 0.
b) Scan Mode: Scan mode is used to control the reset and clock logic. To bypass all the logic that is coming from the main reset to the reset of each flop or to bypass all the logic that is coming from the main clk to the clk of each flop.

6) What is Scan insertion?
A. Scan insertion is the process of replacing the normal flops with the scan flops. Scan flops has a mux before the flop to that has SI (1) , D(0) and SE(select) of the mux.

7) What are the different methods of doing DFT?
A.a) MBIST (Memory Built in self test)
b) Boundry Scan
c) JTAG
d) SOC Test Bus
e) SCAN Chain

8) What is difference between bypass and compressed mode of scan simulation?
A. Compressed mode scan simulation means if we have 1000 inputs then instead of having 1000 scan daisy chains, we add a converter by which we can generate scan daisy chains for all the 1000 inputs using 100 inputs. See the attached pic. llly at the output also we have a converter that converts 1000 outputs into 100 outputs. In this way we reduce the tester time.





9) What are the different faults that can occur in DFT?
a) Stuck at fault : These fault arise due to long wire lines running adjacent to each other. If a bridge is created between these lines then short happens this is called stuck at 1. This can be verified by sending 0. llly if a open is formed then it is called stuck at 0 and can be verified by sending 1 to thescan flop.
b) Transition faults : This fault can occur if the signal strenght is very low and this is not sampled and that can result in a functional problem.

10) What are the different types of tests that we do for DFT?
a) shift mode: In this mode we shift the SI at the scan clock and expect the SO. We can control the clock from outside.
b) Capture : In this mode we change the state of the chip and then we apply the shift pattern. In this way we verify the shift pattern in every state of the chip. We capture the SO and verify the expected pattern at the out. Capture mode operates on at freq.
c) bypass : Explained in #7
d) Compressed : Explained in #7
e) min corner : sdf timing in min corner
f) max corner : sdf timing in max corner
g) Serial : Send pattern to all the scan daisy chain through SI and observe the expected pattern at the SO.
h) Parallel : Parallely send pattern to SI of each scan flop and observe the SO of that scan flop.

RVM PDF

--> Files and Directories
1) All OpenVera source file shall have the ".vr" type
2) All OpenVera aspect-oriented extension source file shall have the ".vra" type (not supported in VCS)
3) All manually written OpenVera header file shall have the ".vri" type
4) Automatically generated Vera header file shall have the ".vrh" extension.
5) Header files corresponding to source files should be automatically generated

What are the improvements that you wanted to make after completing your verifcation?

Bugs in ATE Testing

Bugs in Design

I think bugs can be classified as follows:
1) Reset Bugs: Reset period.
Spec: According to the spec the reset width should not change for continuously 10 clock cycles. This stmt should be true for both low pulse and high pulse.
Bug: Testcase was written to check the low pulse continously for 10 clock cycles. The low pulse check passed. In the same test check for high pulse was made. Because of some bad logic the high pulse was not staying for continously 10 clock pulses. Soon after 2 cycles the high level reset was going low and because of this check we were able to find this bug.

2) Clock Bugs:

3) Register Bugs:

4) Memory Bugs:

5) functional Bugs:

6) Bandwidth Bugs:
Luma component operates at: 78.3% (includes SEI-Loading). [(176x144) / 32371] for 176x144 image size and it takes 32371 pixel-clocks for luma-component.
Chroma component operates at: 73% (includes SEI-Loading). This is low I will try to see if I can optimize in my RTL to get better throughput.
Per frame: 75% (This includes register read/write operation between switching from luma to chroma component processing).

7) Specification Bugs: