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!

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