Multivoltage cells can be used in multi voltage design (Mvdd) in which there are different voltage domains. for e.g.
Special cells are required for implementing a Multi-Voltage design.
1. Level Shifter
2. Isolation Cell
3. Enable Level Shifter
4. Retention Flops
5. Always ON cells
6. Power Gating Switches/MTCMOS switch
Level Shifter: Purpose of this cell is to shift the voltage from low to high as well as high to low. Generally buffer type and Latch type level shifters are available. In general H2L LS's are very simple whereas L2H LS's are little complex and are in general larger in size(double height) and have 2 power pins. There are some placement restrictions for L2H level shifter to handle noise levels in the design. Level shifters are typically used to convert signal levels and protect against sneak leakage paths. With great care, level shifters can be avoided in some cases, but this will become less practicable on a wider scale.
Isolation Cell: These are special cells required at the interface between blocks which are shut-down and always on. They clamp the output node to a known voltage. These cells needs to be placed in an 'always on' region only and the enable signal of the isolation cell needs to be 'always_on'. In a nut-shell, an isolation cell is necessary to isolate floating inputs.
There are 2 types of isolation cells (a) Retain "0″ (b) Retain "1″
Enable Level Shifter: This cell is a combination of a Level Shifter and a Isolation cell.
Retention Flops: These cells are special flops with multiple power supply. They are typically used as a shadow register to retain its value even if the block in which its residing is shut-down. All the paths leading to this register need to be 'always_on' and hence special care must be taken to synthesize/place/route them. In a nut-shell, "When design blocks are switched off for sleep mode, data in all flip-flops contained within the block will be lost. If the designer desires to retain state, retention flip-flops must be used".
The retention flop has the same structure as a standard master-slave flop. However, the retention flop has a balloon latch that is connected to true-Vdd. With the proper series of control signals before sleep, the data in the flop can be written into the balloon latch. Similarly, when the block comes out of sleep, the data can be written back into the flip-flop.
Always ON cells: Generally these are buffers, that remain always powered irrespective of where they are placed. They can be either special cells or regular buffers. If special cells are used, they have thier own secondary power supply and hence can be placed any where in the design. Using regular buffers as Always ON cells restricts the placement of these cells in a specific region.
In a nut-shell, "If data needs to be routed through or from sleep blocks to active blocks and If the routing distance is excessively long or the driving load is excessively large, then buffers might be needed to drive the nets. In these cases, the always-on buffers can be used."
Power Gating Switches/MTCMOS Switch: MTCMOS stands for multi-threshold CMOS, where low-Vt gates are used for speed, and high-Vt gates are used for low leakage. By using high-Vt transistors as header switches, blocks of cells can be switched off to sleep-mode, such that leakage power is greatly reduced. MTCMOS switches can be implemented in various different ways. First, they can be implemented as PMOS (header) or NMOS (footer) switches. Secondly, their granularity can be implemented on a cell-level (fine-grain) or on a block-level (coarse-grain). That is, the switches can be either built into every standard cell, or they can be used to switch off a large design block of standard cells.
Hope this will help you.
Thanks.
Wednesday, November 24, 2010
Saturday, April 17, 2010
Placement grid, manufacturing grid explanation
The manufacturing grid is the smallest resolution of your technology process. The value can be found in the tech lef file, for example:
Cells actually are aligned with the "placement" grid, which is a multiple of the manufacturing grid. The placement grid is really made up of the rows in your floorplan. The rows are composed of SITEs. For example, in the LEF you will see that each std cell references a SITE that is defined either in the std cell LEF or the tech LEF. The std cell SITE will have the same height as your std cells, but the width will be as small as your smallest filler cell. When you create ROWs in your floorplan, you are really laying out a bunch of these SITEs side by side. The std cells then get placed on these rows.
So, as long as you have everything defined correctly - manufacturing grid, SITE definitions, and ROWs in your floorplan, you should always be aligned with the manufacturing grid. Encounter knows what the grid is, and will only place things (cells and wires) on grid. Occasionally, you will find something offgrid - maybe a hand-placed cell, or a hand-routed wire, where you either turned off DRC checks or maybe entered bad coordinates directly into a fp or DEF file. But these days, you really have to work pretty hard to get something offgrid. :-)
MANUFACTURINGGRID 0.005 ;but I always double-check with the sign-off DRC deck to make sure this is correct. Any shapes created in your design must align to this grid, otherwise you will get DRC errors
Cells actually are aligned with the "placement" grid, which is a multiple of the manufacturing grid. The placement grid is really made up of the rows in your floorplan. The rows are composed of SITEs. For example, in the LEF you will see that each std cell references a SITE that is defined either in the std cell LEF or the tech LEF. The std cell SITE will have the same height as your std cells, but the width will be as small as your smallest filler cell. When you create ROWs in your floorplan, you are really laying out a bunch of these SITEs side by side. The std cells then get placed on these rows.
So, as long as you have everything defined correctly - manufacturing grid, SITE definitions, and ROWs in your floorplan, you should always be aligned with the manufacturing grid. Encounter knows what the grid is, and will only place things (cells and wires) on grid. Occasionally, you will find something offgrid - maybe a hand-placed cell, or a hand-routed wire, where you either turned off DRC checks or maybe entered bad coordinates directly into a fp or DEF file. But these days, you really have to work pretty hard to get something offgrid. :-)
Friday, April 16, 2010
site in lef file
A site is a defination (a rectangle, I think) for placing a object. For example, all the standard celll use the same site.
Physical design clean netlist
The netlist that is input to physcial design should not have any
assign statements, unmapped logic( logic not mapped to any tech cells), combinational timing loops, 1'b0 and 1'b1 statements.
All the ports of cell instances even though they are not connected should be present or defined in the netlist.
In order that the unconnected pins are not removed from the netlist for a cell instantiation use the below command in dc shell
set verilogout_show_unconnected_pins true
The assign statements are generated in the netlist due to the following reasons.
1) feedthroughs ( input directly assinged to output; to avoid this use the buffer in betwn them)
2) multi ports nets ( two outputs directly driving the same net)
3) tri-state drivers in the design at the intermediate level ( tri-state drivers are used only at the IO level of design in ASIC0
To avoid the assign statements in the netlist use the following command
set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants -all
assign statements, unmapped logic( logic not mapped to any tech cells), combinational timing loops, 1'b0 and 1'b1 statements.
All the ports of cell instances even though they are not connected should be present or defined in the netlist.
In order that the unconnected pins are not removed from the netlist for a cell instantiation use the below command in dc shell
set verilogout_show_unconnected_pins true
The assign statements are generated in the netlist due to the following reasons.
1) feedthroughs ( input directly assinged to output; to avoid this use the buffer in betwn them)
2) multi ports nets ( two outputs directly driving the same net)
3) tri-state drivers in the design at the intermediate level ( tri-state drivers are used only at the IO level of design in ASIC0
To avoid the assign statements in the netlist use the following command
set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants -all
Thursday, April 15, 2010
Formula to calculate the distance between adjacent macros
No of pins x metal pitch
Distance between the macros = -------------------------------
(no of metal layers used /2)
Consider one horizontal and vertical metal layer as one resource.
For 4 ML process, the denominator comes out to 2 and for 6 ML process it comes out to 3.
Finally calculate the value for two adjacent macros by doubling the above value
Distance between the macros = -------------------------------
(no of metal layers used /2)
Consider one horizontal and vertical metal layer as one resource.
For 4 ML process, the denominator comes out to 2 and for 6 ML process it comes out to 3.
Finally calculate the value for two adjacent macros by doubling the above value
Halo,blockage,fence, region definitions
Halo: Is not a hard constraint.
Suppose say, a routing halo, It won't stop you routing on the specified place if you give halo there.
But, It would certainly stop you from routing in the specified blockage.
Fence: If you have different modules defined in your netlist you would generally prefer them to keep in a specified area where you don't want to keep other module cells.
Tool neither allow other group cells to sit in that perticular fence nor allow the cells from the group out of fence.
Guide: You have the flexibility of moving the cells in and out of the design area.
Region: You could move other group cells into the region but not the region cells to out of the area.
All these are the ways of representations to tell the tool what to do exactly.
Suppose say, a routing halo, It won't stop you routing on the specified place if you give halo there.
But, It would certainly stop you from routing in the specified blockage.
Fence: If you have different modules defined in your netlist you would generally prefer them to keep in a specified area where you don't want to keep other module cells.
Tool neither allow other group cells to sit in that perticular fence nor allow the cells from the group out of fence.
Guide: You have the flexibility of moving the cells in and out of the design area.
Region: You could move other group cells into the region but not the region cells to out of the area.
All these are the ways of representations to tell the tool what to do exactly.
difference between placement blockage and Halo?
placement blockage and halo used to block other cell like standard cell or other macro to be placed in that area. So both placement blockage and halo have the same functionality.
THe different between them is halo stick with the macro like EBB. If EBB move, the halo move with it. But placement blockage will stick to the same location which you have defined for them. So for summary, halo move with the EBB movement but placement blockage location will remain although your macro move.
THe different between them is halo stick with the macro like EBB. If EBB move, the halo move with it. But placement blockage will stick to the same location which you have defined for them. So for summary, halo move with the EBB movement but placement blockage location will remain although your macro move.
Subscribe to:
Posts (Atom)