Friday, October 15, 2010

What are RTL, Gate, Metal and FIB fixes? What is a "sewing kits"?

There are several ways to fix an ASIC-based design. >From easiest to most extreme:


RTL Fix -> Gate Fix -> Metal Fix -> FIB Fix

First, let's review fundementals. A standard-cell ASIC consists of at least 2 dozen manufactured layers/masks. Lower layers consists of materials making up the actual CMOS transistors and gates of the design. The upper 3-6 layers are metal layers used to connect everything together. ASICs, of course, are not intended to be flexible like an FPGA, however, important "fixes" can be made during the manufacturing process. The progression of possible fixes in the manufacturing life cycle is as listed above.


An RTL fix means you change the Verilog/VHDL code and you resynthesize. This usually implies a new Plance&Route. RTL fixes would also imply new masks, etc. etc. In other words - start from scratch.


A Gate Fix means that a select number of gates and their interconections may be added or subtracted from the design (e.g. the netlist). This avoids resynthesis. Gate fixes preserve the previous synthesis effort and involve manually editing a gate-level netlist - adding gates, removing gates, etc. Gate level fixes affect ALL layers of the chip and all masks.


A Metal Fix means that only the upper metal interconnect layers are affected. Connections may be broken or made, but new cells may not be added. A Sewing Kit is a means of adding a new gate into the design while only affecting the metal layers. Sewing Kits are typically added into the initial design either at the RTL level or during synthesis by the customer and are part of the netlist. A Metal Fix affects only the top layers of the wafers and does not affect the "base" layers.


Sewing Kits are modules that contain an unused mix of gates, flip-flops or any other cells considered potentially useful for an unforseen metal fix. A Sewing Kit may be specified in RTL by instantiating the literal cells from the vendor library. The cells in the kit are usually connected such that each cell's output is unconnected and the inputs are tied to ground. Clocks and resets may be wired into the larger design's signals, or not.


A FIB Fix (Focussed Ion Beam) Fix is only performed on a completed chip. FIB is a somewhat exotic technology where a particle beam is able to make and break connections on a completed die. FIB fixes are done on individual chips and would only be done as a last resort to repair an otherwise defective prototype chip. Masks are not affected since it is the final chip that is intrusively repaired.


Clearly, these sorts of fixes are tricky and risky. They are available to the ASIC developer, but must be negotiated and coordinated with the foundry. ASIC designers who have been through enough of these fixes appreciate the value of adding test and fault-tolerant design features into the RTL code so that Software Fixes can correct mior silicon problems!

Thursday, October 7, 2010

A $ comes for free

A $ comes for free 

It took me a while (about 1.5 year of working with SV), but I’ve just realised that dynamic arrays are just plain useless: Whatever a dynamic array can do, a queue can do much better. A queue could be resized using new[] just like an array, but it would also be resized automatically when you add an element, or a list of elements. You could use two variables to slice a queue, which you can’t do with an array, and this alone is a good enough reason to forget about dynamic arrays for eternity. And, in general, every function or language structure that would work with a dynamic array, would also work with a queue. You could also randomize queues of course. 
And why did it take me such a long time to figure this out? Obviously, because no one in his right mind expects a language to have some outright redundant constructs. I was assuming that if dynamic arrays are there, then there must be some reason, some hidden super-power that I haven’t come-across yet. 
So, the bottom line is, whenever you write something like that: 
int a[]; 
Just go ahead and place that $ inside: 
int a[$]

Implicit Net Declartions in Verilog and Systemverilog

Implicit net declarations
Gotcha: Mis-typed identifiers may infer an implicit net instead of a syntax error

What does a compiler do when it encounters an undeclared identifier? The answer to this
question depends on the context in which the undeclared identifier is used.

·         If an undeclared identifier is used on the right or left-hand side of a procedural assignment, then a compilation or elaboration error occurs.

·         If an undeclared identifier is used on the right-hand side of a continuous assignment, then a compilation or elaboration error occurs.

·         If an undeclared identifier is used on the left-hand side of a continuous assignment, then animplicit net declaration is inferred, and no error or warning is reported.

·         If an undeclared identifier is used as a connection to an instance of a module, interface, program, or primitive, then an implicit net is inferred, and no error or warning is reported.

The last two rules above are gotchas, as is illustrated in the following example:

module bad_adder (input wire a, b, ci,
output wire sum, co);
wire n1, n2, n3;
xor g1 (n1, a, b);
xor g2 (sum, nl, ci); // GOTCHA!
and g3 (n2, a, b, c); // GOTCHA!
and g4 (n3, n1, ci);
or g5 (co, n2, n3);
endmodule

One gotcha in this example is the declaration of n1 (“en-one”) but the usage of nl (“en-ell”) in the g2 primitive instance. Another gotcha is an extra identifier, c, in the second g3 primitive instance. These typos are not syntax errors. Instead, they infer implicit nets in the design, causing
functional errors that must be detected and debugged. GOTCHA! This example comes from a debugging lab in Sutherland HDL’s Verilog training course (but
without the GOTCHA comments). It is surprising how difficult the two typos in the netlist can be to find. Imagine how much more difficult a simple typo would be to find in a one-million gate netlist with several layers of design hierarchy. Why does Verilog allow this gotcha? Because, like many gotchas, the ability to have implicit data types automatically inferred can be useful, when not abused. One of the benefits of implicit data types is that in a large, multi-million gate design
that has thousands of interconnecting wires, it is not necessary to explicitly declare every wire. How to avoid this gotcha: There are two ways to avoid this implicit data type gotcha. Verilog provides a ‘default_nettype none compiler directive. When this directive is set, implicit data types are disabled, which will make any undeclared signal name a syntax error. A limitation of this directive is that the benefits of implicit data types are also lost. Another limitation is that
compiler directives are not bound by design blocks, or even by source code files. If the ‘default_nettype none directive is turned on in one file, it can affect the compilation of other files, which is yet another GOTCHA!. To avoid this gotcha, the directive ‘default_nettype wire should be added at the end of each file where implicit nets have been turned off.

‘default_nettype none // turn off implicit data types
module adder (input wire a, b, ci,
output wire sum, co);
wire n1, n2, n3;
xor g1 (n1, a, b);
xor g2 (sum, nl, ci); // ERROR! nl is not declared
and g3 (n2, a, b, c); // ERROR! c is not declared
and g4 (n3, n1, ci);
or g5 (co, n2, n3);
endmodule
‘default_nettype wire // turn implicit nets on again to avoid side-effects

SystemVerilog provides two convenient short cuts for connecting nets to module instances, . and .*. These shortcuts remove the repetition in Verilog named port connections. By reducing the number of times a signal name must be typed, the possibility of typographical errors is also reduced. The . and .* shortcuts also require that all nets be explicitly declared. The shortcuts will not infer an implicit data type due to a typo. Another advantage of these SystemVerilog shortcuts is that they are local to the module in which they are used. The shortcuts do not affect other design blocks, the way compiler directives can.
module adder (input wire a, b, ci,
output wire sum, co);
...
Endmodule

module top;
wire a, b, ci;
wire s1, s2, s3, c1, c2, c3;
adder i1 (.a(a), .b(b), .ci(ci), .sum(s1), .co(c1) ); // Verilog style
adder i2 (.a, .b, .ci, .sum(s2), .co(c2) ); // SystemVerilog .name style
adder i3 (.*, .sum(s3), .co(c3) ); // SystemVerilog .* style
endmodule

Monday, September 27, 2010

Questasim: How to force an internal signal from another signal through TCL script?

The 'force' command available in Questa / ModelSim allows force of value but not signal onto a signal.

Solution

The following example TCL script will do the job:


  when /tb/dut/signal_b {
        force /tb/dut/signal_a [examine /tb/dut/signal_b]   }


where, /tb/dut/signal_a is the source and /tb/dut/signal_b is the destination signal.


Note that in the above case one should provide visibility to the internal object(s) during simulation by either using vsim option -voptargs="+acc" when in optimized(vopt) mode or using vsim option -novopt to be in non-optimized (novopt) mode. Please see User's Manual for details on internal object visibility during simulation - see the section "Preserving Object Visibility for Debugging Purposes".


For details on how to use TCL script, please refer to User's Manual under chapter "Tcl and Macros".


One could force value of a signal onto another signal in the heirarchy within the source code by using Signal Spy feature in Questa / ModelSim. Refer to section "init_signal_driver"

Questasim: How to find all signals with X value in simulation

Modelsim/Questa currently doesn't have a built in command to list all X signals in the design.

Solution

 The following is an example of a TCL script that can be used to print out a list of all signals in the design that have an X or U value at the current simulation time.

foreach item [find signals -r /*] {

    if { [examine -expr $item'hasX] eq "true"} {

        echo "$item [examine $item]"

}

}


To run this script:

1) Save the code to a file.

2) On the modelsim command line or transcript use the 'do' command followed by the path and name of the script file to run the script. If the file was saved in the current directory as "script.do" the command would look like this:

> do script.do


The following is a brief explanation of the script functionality.

The script uses the 'find' command to build an array recursively from the root of the design hierarchy of all signals, and then that array is iterated through a foreach loop.

foreach item [find signals -r /*] {

The following line tests if each item has an X or U value

if { [examine -expr $item'hasX] eq "true"} {


Finally, if it does, the signal and its value are printed to the transcript.

echo "$item [examine $item]"


Tuesday, August 10, 2010

Perl Script to checkin the Locally modified files into CVS

The following script will checkin the locally modified files into CVS.
Perl Script to checkin the Locally modified files into CVS
Steps
1) Run cvs stat . command direct the output into one log file
2) Parse log file created in step1 via perl script and create another file which contains the list of file that need to be updated.
3) Run the cvs ci command on all the files created in Step2