Details

Published: Friday, 12 October 2018 04:54

Hits: 3267

LEF : library exchange format - developed by cadence
-----------------------------
An ASCII data format, used to describe a standard cell library. Includes the design rules for routing and the Abstract of the cells, no information about the internal netlist of the cells. Usually kept as 2 files, a tech lef file, and a design lef file.

A LEF file contains the following sections:
1. Technology: layer, design rules, via definitions, metal capacitance
2. Site: Site extension
3. Macros: cell descriptions, cell dimensions, layout of pins and blockages, capacitances.

1. The technology is described by the Layer and Via statements. To each layer the following attributes may be associated:
-type: Layer type can be routing, cut (contact), masterslice (poly, active), overlap.
-width/pitch/spacing rules
-direction
-resistance and capacitance per unit square
-antenna Factor

Manufacturing Grid: Defines the manufacturing grid for the design. The manufacturing grid is used for
geometry alignment. When specified, shapes and cells are placed in locations that
snap to the manufacturing grid.
MANUFACTURINGGRID value ;

I. Layers are defined in process order from bottom to top
poly masterslice
cc cut
metal1 routing
via cut
metal2 routing
via2 cut
metal3 routing

A. Cut Layer definition: Defines contact layer (top layer and bottom layer) for via

LAYER layername
TYPE CUT;
SPACING => Specifies the minimum spacing allowed between via cuts on the same net or different nets. This value can be overridden by the SAMENET SPACING statement (we are going to use this statement later)
END layerName

B. Implant Layer definition: Defines implant layers in the design. Each layer is defined by assigning it a name and simple spacing and width rules. These spacing and width rules only affect the legal cell placements. These rules interact with the library methodology, detailed placement, and filler cell support.

LAYER layerName
TYPE IMPLANT ;
SPACING minSpacing
END layerName

C. Masterslice or Overlap Layer definition: Defines masterslice (nonrouting) or overlap layers in the design.
Masterslice layers are typically polysilicon layers and are only needed if the cell MACROs have pins on the polysilicon layer.
Overlap layer is used for overlap checking for rectilinear blocks (i.e L shaped blocks). Obstruction descriptions in the macro obstruction statements refer to the overlap layer

LAYER layerName
TYPE {MASTERSLICE | OVERLAP} ;
...

D. Routing Layer definition
LAYER layerName
TYPE ROUTING ;
DIRECTION {HORIZONTAL | VERTICAL} ;
PITCH distance;
WIDTH defWidth;
OFFSET distance ;
SPACING minSpacing;
RESISTANCE RPERSQ value ; => Specifies the resistance for a square of wire, in ohms per square. The resistance of a wire can be defined as RPERSQU x wire length/wire width
CAPACITANCE CPERSQDIST value ; => Specifies the capacitance for each square unit, in picofarads per square micron. This is used to model wire-to-ground capacitance.


II. Via: Defines vias for usage by signal routers. Default vias have exactly three layers used: a cut layer, and two layers that touch the cut layer (routing or masterslice). The cut layer rectangle must be between the two routing or masterslice layer rectangles.

VIA viaName DEFAULT TOPOFSTACKONLY
FOREIGN foreignCellName [pt [orient]] ;
RESISTANCE value ;
{LAYER layerName ; => layer1, layer2 and cut layer specified here
{RECT pt pt ;} ...} ...
END viaName

Via Rule Generate: Defines formulas for generating via arrays. Use the VIARULE GENERATE statement to cover special wiring that is not explicitly defined in the VIARULE statement. Rather than specifying a list of vias, we can specify viarule to generate cut layer geometries.

VIARULE viaRuleName GENERATE
LAYER routingLayerName ;        => layer1
{ DIRECTION {HORIZONTAL | VERTICAL} ;
OVERHANG overhang ;
METALOVERHANG metalOverhang ;
| ENCLOSURE overhang1 overhang2 ;}
LAYER routingLayerName ;        => layer2
{ DIRECTION {HORIZONTAL | VERTICAL} ;
OVERHANG overhang ;
METALOVERHANG metalOverhang ;
| ENCLOSURE overhang1 overhang2 ;}
LAYER cutLayerName ;            => cut layer
RECT pt pt ;
SPACING xSpacing BY ySpacing ;
RESISTANCE resistancePerCut ;
END viaRuleName

Same-Net Spacing: Defines the same-net spacing rules. Same-net spacing rules determine minimum spacing between geometries in the same net and are only required if same-net spacing is smaller than different-net spacing, or if vias on different layers have special stacking rules.
These specifications are used for design rule checking by the routing and verification tools.
Spacing is the edge-to-edge separation, both orthogonal and diagonal.

SPACING
SAMENET layerName layerName minSpace [STACK] ; ...
END SPACING

------
2. Site
SITE siteName
CLASS {PAD | CORE} ;
[SYMMETRY {X | Y | R90} ... ;] (will discuss this later in macro definition)
SIZE width BY height ;
END siteName

------
3. Macro
MACRO macroName
[CLASS
{ COVER [BUMP]
| RING
| BLOCK [BLACKBOX]
| PAD [INPUT | OUTPUT |INOUT | POWER | SPACER | AREAIO]
| CORE [FEEDTHRU | TIEHIGH | TIELOW | SPACER | ANTENNACELL]
| ENDCAP {PRE | POST | TOPLEFT | TOPRIGHT | BOTTOMLEFT | BOTTOMRIGHT}
}
;]
[SOURCE {USER | BLOCK} ;]
[FOREIGN foreignCellName [pt [orient]] ;] ...
[ORIGIN pt ;]
[SIZE width BY height ;]
[SYMMETRY {X | Y | R90} ... ;]
[SITE siteName ;]
[PIN statement] ...
[OBS statement] ...

Macro Pin Statement
PIN pinName
FOREIGN foreignPinName [STRUCTURE [pt [orient] ] ] ;
[DIRECTION {INPUT | OUTPUT [TRISTATE] | INOUT | FEEDTHRU} ;]
[USE { SIGNAL | ANALOG | POWER | GROUND | CLOCK } ;]
[SHAPE {ABUTMENT | RING | FEEDTHRU} ;]
[MUSTJOIN pinName ;]
{PORT
[CLASS {NONE | CORE} ;]
{layerGeometries} ...
END} ...
END pinName]

Macro Obstruction Statement
OBS
{ LAYER layerName [SPACING minSpacing | DESIGNRULEWIDTH value] ;
RECT pt pt ;
POLYGON pt pt pt pt ... ;
END


-----------------------
TI tech lef file: pml30_lbc8_tech_3layer.lef
It has general info, then defines layers, vias, viarules, and lastly spacing

VERSION 5.4 ;
NAMESCASESENSITIVE ON ;
BUSBITCHARS "[]" ;
DIVIDERCHAR "/" ;
UNITS
  DATABASE MICRONS 2000 ; => conversion factor from lef to def is 2000. means numbers in lef file should be multiplied by 2000 before being used in def file.
END UNITS

MANUFACTURINGGRID 0.100 ;

--overlap layer --
LAYER OVERLAP
    TYPE OVERLAP ;
END OVERLAP

#poly and cont layers are there only in lbc5 and earlier tech files for 2 metal layer files. Router routes on all layers in the tech lef file that have "TYPE ROUTING", so, router will start from default bottom layer, which may be POLY or MET1, depending on this file.

--poly and CONT layer --
LAYER POLY
  TYPE          ROUTING ;
  ...
END POLY

LAYER CONT
  TYPE  CUT ;
  SPACING       0.7 ; => min spacing b/w vias is 0.7um
END CONT

--metal1 layer --
LAYER MET1
TYPE        ROUTING ;
  ANTENNAAREARATIO 100.0 ; => max legal ant ratio, using area of metal wire that is not connected to diffusion diode
  ANTENNADIFFAREARATIO PWL ( ( 1 1000 ) ( 100 10000 ) ( 500 50000 ) ) ; => Specifies the antenna ratio, using the area of the metal wire connected to the diffusion diode. You can supply an explicit ratio value or specify piece-wise linear format (PWL (diff_area1 ratio1) (diff_area2 ratio2) .. ), in which case the ratio is calculated using linear interpolation of the diffusion area and ratio input values. So in our ex, it means that if diffusion area of 1 is connected to the metal wire, then a ratio of 1000 should be used instead of a ratio of 100. If diffusion area of 100 is connected to the metal wire, then a ratio of 10000 should be used and so on. Note that with diffusion diode connected, antenna ratio is not infinity, as a diff diode can only allow so much current to pass thru it.
  DIRECTION    HORIZONTAL ;
  PITCH        1.7  ;
  OFFSET    0  ;
  WIDTH        0.6 ; => M1 width is 0.6, but M2 and M3 width is 0.8
  SPACING    0.7 ; => min spacing is 0.7um for wires less than 15um wide for M1,M2,M3.
  SPACING    1.5 RANGE 15 9999 ; => min spacing is 1.5 (instead of 0.7) for wires with width b/w 15 to 9999.
  AREA 1.92 ; => min area for M1 is 1.92um^2
  //res/cap/edge cap values below used to be there, but moved to cap table now.
  RESISTANCE  RPERSQ 0.066 ; => res is 0.06ohm/sq (sq=W/L)
  CAPACITANCE CPERSQDIST 0.1 ; => cap is 0.1pf per sq um
  EDGECAPACITANCE 0.1 ;
END MET1

--via1 layer --
LAYER VIA1
  TYPE    CUT ; => It's a cut layer and not routing layer
  SPACING    0.8 ; => min spacing b/w vias is 0.7um
END VIA1

--similarly for MET2, VIA2, MET3 --

--Vias--
-- via defined here is as such:  met1 is rect of (1.2,0.8), via1 is square of (0.6,0.6), met2 is rect of (0.8,1.0). met1 and met2 are not symmetric, since met1 runs horizontal with min width=0.6um while met2 runs vertical with min width=0.8um.
VIA VIAS12 DEFAULT
  LAYER MET1 ;
    RECT -0.600 -0.400 0.600 0.400 ;
  LAYER VIA1 ;
    RECT -0.300 -0.300 0.300 0.300 ;
  LAYER MET2 ;
    RECT -0.400 -0.500 0.400 0.500 ;
END VIAS12
 
--similarly for VIAS12A/B/AB, VIAS23, VIAS12DCN/E/S/W (double cut vias with orientation North,East,South,West), VIAS23DCN/E/S/W --

--top of stack via --
VIA VIAS23T DEFAULT TOPOFSTACKONLY
  LAYER MET2 ;
    RECT -0.700 -0.700 0.700 0.700 ;
  LAYER VIA2 ;
    RECT -0.400 -0.400 0.400 0.400 ;
  LAYER MET3 ;
    RECT -0.600 -0.400 0.600 0.400 ;
END VIAS23T

--viarule --  These specify rules for multiple via generation as in power rings.
#It describes a formula for generating via cuts using DIRECTION. If you specify DIRECTION, the WIDTH range is based on the connecting horizontal or vertical wire, not the layer of the connecting wire. Therefore, a horizontal wire that is between 0.6 and 14.9 units wide and a vertical wire that is between 0.8 and 14.9 units wide will trigger ViaGen12, independent of whether the horizontal wire is M1 or M2. It will create vias of 0.6x0.6 with an overhang of 0.3 on all sides and spacing of 1.4 on all sides b/w adjacent vias
VIARULE VIAGEN12 GENERATE
  LAYER MET1 ;
    DIRECTION HORIZONTAL ;
    WIDTH 0.6 TO 14.9 ;
    OVERHANG 0.3 ;
  LAYER MET2 ;
    DIRECTION VERTICAL ;
    WIDTH 0.8 TO 14.9 ;
    OVERHANG 0.3 ;
  LAYER VIA1 ;
    RECT -0.3 -0.3 0.3 0.3 ;
    SPACING 1.4 BY 1.4 ;
END VIAGEN12

--similarly for viagen23--

--spacing--
SPACING
  SAMENET VIA1  VIA1    0.800 ;
  SAMENET VIA1  VIA2    0 STACK ;
  SAMENET VIA2  VIA2    0.900 ;
END SPACING

END LIBRARY

-----------------------------------------------
TI core lef file: pml30_lbc8_core_2pin.lef
It has PnR info for all stdcells.

--initial info same as that for tech file, i.e version, units,etc--
#SITE => defines smallest size cell (1.7um is the pitch). It has cell height defined for CORESITE. All rows are in CORESITE (in the .def file), so PnR tool understands that it has to route VDD/VSS every 13.6um.
 SITE CORESITE
 SYMMETRY Y ;
 CLASS CORE ;
 SIZE 1.7 BY 13.600 ;
 END CORESITE

#MACRO for all stdcells.
MACRO IV110 => inv x1
  CLASS CORE ;
  FOREIGN IV110 0.000 0.000 ;
  SIZE 5.100 BY 13.600 ; => size 3 pitch wide.
  ORIGIN 0.0 0.0 ;
  SYMMETRY X Y ;
  SITE CORESITE ;
  PIN A => i/p pin A. i/p pins are all in Met1
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT => pin shape in metal1
      LAYER MET1 ;
      RECT 1.300 5.800 3.100 6.800 ;
      RECT 1.300 5.800 2.100 7.400 ;
    END
        ANTENNAGATEAREA 2.580 ; => antenna gate area to use for antenna ratio (AR) calc
  END A
  PIN Y => o/p pin Y. o/p pins are all in Met1, except for few complex cells, where it's in Met2, but internally routing is still all in Met1
    DIRECTION OUTPUT ;
    USE SIGNAL ;
    PORT
      LAYER MET1 ;
      RECT 3.000 8.100 4.700 9.100 ;
      RECT 3.000 7.900 4.600 9.100 ;
      RECT 3.800 2.800 4.600 9.100 ;
      RECT 3.700 2.800 4.700 3.800 ;
    END
    ANTENNADIFFAREA 1 ; => o/p pin is always connected to diffusion area, so specifies diff area to use for AR calc
  END Y
  PIN VSS => gnd pin VSS
    DIRECTION INOUT ;
    USE GROUND ;
    SHAPE ABUTMENT ;
    PORT
      LAYER MET1 ;
      RECT 0.000 -1.900 5.100 1.900 ;
      RECT 0.700 -1.900 1.700 3.500 ;
    END
  END VSS
  PIN VDD  => pwr pin VDD
    DIRECTION INOUT ;
    USE POWER ;
    SHAPE ABUTMENT ;
    PORT
      LAYER MET1 ;
      RECT 0.000 11.700 5.100 15.500 ;
      RECT 0.700 10.200 1.700 15.500 ;
    END
  END VDD
  OBS => metal1 obstruction layer, we only have obs in met1 as stdcells only use Met1 internally to connect.
    LAYER MET1 ;
    RECT 13.400 4.000 14.200 8.300 ;
    RECT 16.000 6.200 16.800 8.300 ;
  END
END IV110

--similarly for all other stdcells--

END LIBRARY

-------------------------------------------

Details

Published: Friday, 12 October 2018 04:53

Hits: 709

UVM: unified verification methodology

UVM was created in 2009. It's just a bunch of sv files with lot of tasks, functions, classes, etc already written, so that you don't have to write it. You just have to learn how to call them.

NOTE: In sv, classes are created at runtime, as opposed to verilog/vhdl, where all instances are elaborated before runtime.

Go thru SV section, and then come back here to go thru this detailed SV verification document written very nicely. It explains basics of verification (Not UVM necessarily).

Link => Springer_-_SystemVerilog_for_Verification.pdf

Running uvm in irun:

We can use irun/xrun with -uvm option which then allows us to access cadence uvm library. Top level design units that show while compiling are uvm_pkgs (uvm_pkg.sv cdns_uvm_pkg.sv cdns_uvmapi cdns_assert2uvm_pkg) and tb.sv

uvm library files are usually installed in these paths for Cadence simulator:

ies: /apps/cds/incisiv/14.20.01/tools/methodology/UVM/CDNS-1.1d/additions/sv/ => for uvm 1.1 (all files are system verilog files)

xcelium: /home/.../cadence/xcelium/19.01.v001/tools/methodology/UVM/CDNS-1.2/sv/ => for uvm 2.0

Within this "sv" dir are multiple dir. Source code is in subdir named "src"

src/uvm_pkg.sv => It's a package, with bunch of include files (*.svh) in it

src/uvm_macros.svh => It has bunch of include files for macro defn (*_defines.svh) in it. This is not a package, just a regular file with include files which have various macro defines (i.e `define uvm_delay(TIME) #(TIME);)

There are bunch of more dir in "src" that has all of these include files, and all other files needed by uvm (i.e src/base/uvm_root.svh has run_test task, ..).

Below is the simplest UVM testbench written to test uvm functionality

sample tb testbench: => no test being called in this. Just prints "Hello"

module tb;

import uvm_pkg::*; // uvm package imported, these 2 lines needed
`include "uvm_macros.svh" //uvm macro included (to get all defn)

initial begin
  `uvm_info("TEST", "Hello!!!", UVM_LOW) //NOTE: no semicolon at end since it's replaced by the macro defn found in uvm_macros.svh
end

endmodule : tb

cmd: irun -uvm tb.sv => -uvm compiles uvm pkgs (uvm_pkg.sv cdns_uvm_pkg.sv). Then module tb is compiled. Then ncsim is run, which causes "initial" block in tb to run. It prints "HELLO!!!" from that block

screen o/p:
-----------
SVSEED default: 1                                                               
ncsim> source /apps/cds/incisiv/14.20.017p1/tools/inca/files/ncsimrc                      
ncsim> source /apps/cds/incisiv/14.20.017p1/tools/methodology/UVM/CDNS-1.1d/additions/sv/files/tcl/uvm_sim.tcl    => This has bunch of tcl proc which parse various uvm cmds for option correctness, before calling the uvm package (i.e uvm_version proc finally calls uvm_pkg::uvm_version)
UVM_INFO tb.sv(12) @ 0: reporter [TEST] Hello!!!
ncsim: *W,RNQUIE: Simulation is complete.       
ncsim> exit    

----------------------------------------------
Now we modify tb above to include a test to run  
----------------------------------------------
sample tb testbench: =>  test being called in this

module tb;

// uvm package/macro, these 2 lines below needed
import uvm_pkg::*;
`include "uvm_macros.svh"

 wire a, b,..; //nets, reg etc defined which are used here

 digtop u_digtop (.A(wire1), ...); //inst digtop
 pullup(GPIO1); //inst other modules
 i2c_bfm u_i2c_bfm (.SCL(SCL), ...);

 always @(a) begin .. end //for capturing events

 //simple interface for interfacing internal nets => we always connect dut signals to interface, and then interface interacts with our uvc. This is to make it resuable. We use virtual interface (which then needs to be connected to real interface). config database is used to set these virtual i/f.
 gpio_interface gpio_if (.pclk(`TB.u_dig_top.clk_16m),.data(..),...);
 adc_interface adc_if (....);

//ex of interface: (see pg 300 of UVM lecture notes from cadence)
interface (input clk, rst);
 logic [7:0] in_data;
 logic ...;
endinterface

 //configuring interface ..
initial begin
 //components can be configured using uvm_config_db.  uvm_config_db is a class that has set and get function defined in it. We can supply the name of field, and value to be set or get using this uvm_config_db
 uvm_config_db #(virtual gpio_interface)::set(null, "*", "gpio_vif", gpio_if); //gpio_vif is set to value gpio_if
 uvm_config_db #(virtual adc_interface)::set(null, "*", "adc_vif", adc_vif);
end

initial begin
  `uvm_info("TEST", "Hello!!!", UVM_LOW)
   run_test(); // calling test to run. run_test is a task in .../CDNS-1.1d/sv/src/base/uvm_root.svh  [task uvm_root::run_test(string test_name=""); ... endtask] which calls run_phases [fork ... uvm_phase::m_run_phases(); join_none] and finally does $finish, once all done. All uvm tasks are in base dir. i.e base/uvm_phase.svh, etc. So, no explicit $finish needed in our testcase.
end

initial begin
  #10ms;
  $finish; //for sim timeout (there's already a $finish in uvm run_test call)
end

//code below differs for separate testcases. So, we can keep below code in separate files  so that each test has it's own tc.sv file. similar to how we do our regular testcases in non-uvm env. In this ex, testcase is part of same file as tb.

/////////////// testcase start = base_test.sv /////////////
NOTE: classes are same as modules. They have local signals, function, etc
`define testname base_test

class `testname extends uvm_test; //uvm_test is built in uvm class for tests.
  `uvm_component_utils(`testname)

  byte mask[]; //dynamic byte array of undefined length

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction : new

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);        
    `uvm_info("TEST", "Running base Test", UVM_LOW)
  endfunction : build_phase
   
  //more func and task (everything below optional and not included for irun)
  virtual function void end_of_elaboration_phase(uvm_phase phase);
     super.end_of_elaboration_phase(phase);        
    `uvm_info("TEST", "End of elab: Sample Test", UVM_LOW)
  endfunction : end_of_elaboration_phase
   
  function init_test_seq(test_seq_base test_seq);
     test_seq.env = this.env; ...
  endfunction

  //tasks
  task run_phase(uvm_phase phase); //NOTE: we can also use task "main_phase" instead of "run_phase"
    phase.raise_objection(this, "base_test"); //raise obj, uvm keeps track of how many obj raised
    ... // all tests done here
    phase.drop_objection(this, `teststr);      // drop obj, only when all obj dropped, $finish called by uvm
  endtask:

   //more tasks
   task i2c_read(input bit [6:0] addr, input byte reg output byte data[]);
    ...
   endtask

endclass : base_test
/////////////////////// testcase end /////////////
   
endmodule : tb

cmd:
---
irun -uvm tb.sv => calls default test (base_test) to run.
irun -uvm tb.sv +UVM_TESTNAME=base_test => or we can provide test name explicitly if there are many tests. same as above if only 1 test.
If base_test is in separate file (other than tb.sv), then we need to give name of that file too so that irun can compile/elaborate it, i.e
irun -uvm tb.sv base_test.sv +UVM_TESTNAME=base_test

screen o/p:
----------
UVM_INFO tb.sv(12) @ 0: reporter [TEST] Hello!!!
UVM_INFO @ 0: reporter [RNTST] Running test base_test...
UVM_INFO tb.sv(29) @ 0: uvm_test_top [TEST] Running Base Test  => prints "Running Base test" from function above      

--- UVM Report catcher Summary ---
Number of demoted UVM_FATAL reports  :    0
Number of demoted UVM_ERROR reports  :    0
Number of demoted UVM_WARNING reports:    0
Number of caught UVM_FATAL reports   :    0
Number of caught UVM_ERROR reports   :    0
Number of caught UVM_WARNING reports :    0

--- UVM Report Summary ---

** Report counts by severity
UVM_INFO :    3             
UVM_WARNING :    0          
UVM_ERROR :    0            
UVM_FATAL :    0            
** Report counts by id      
[RNTST]     1               
[TEST]     2                
Simulation complete via $finish(1) at time 0 FS + 179 => NOTE: here sim finishes via $finish
/apps/cds/incisiv/14.20.017p1/tools/methodology/UVM/CDNS-1.1d/sv/src/base/uvm_root.svh:457     $finish;
ncsim> exit                           

-----------------------------------
we can create another testcase called sample_test which can extend base_test (in sample_test.sv)
//////////////////////// sample_test.sv => testcase start /////////////

`define testname sample_test
class `testname extends base_test;
  `uvm_component_utils(`testname)

  byte mask[]; //dynamic byte array of undefined length

 //these function defn below may not be needed
 extern function new(string name = `teststr, uvm_component parent = null); //defined as external function, so compiler looks for these function outside the class
 extern function void build_phase(uvm_phase phase);
 extern task run_phase(uvm_phase phase);
 extern task main_phase(uvm_phase phase);

endclass

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction : new

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);        
    `uvm_info("TEST", "Running sample Test", UVM_LOW)
  endfunction : build_phase
   
  //more functions
  function check_val (byte data1, int i);
     ....
  endfunction

  //main task
  task `testname::main_phase(uvm_phase phase);
   int a,b;
   super.main_phase(phase); //super fn always called for phases before doing anything else
   phase.raise_objection(this, "sample_test"); //raise obj
     $display(`testname:: main_phase");
     #10; addr = ... //write like normal task
     #1ms;
   phase.drop_objection(this, `teststr);      // drop obj
  endtask: main_phase
/////////////////////// testcase end /////////////

-------------------------------
see UVM lect from Cadence 5 day workshop:

tb consists of "reusable verification component (UVC)" + DUT. It also has sv i/f to link VC to DUT.
testcases can be put in separate files or within tb.

UVC consists of
 - sequencer = to create high level data (as do_read), either random or under control of test data (has TX transmitter)
 - driver (BFM=Bus functional Model) = to drive i/f signals to DUT (from high level to low level signals)
 - Monitor = to capture activity on i/f for coverage, checking and analysis (has RX receiver)

Top level of UVC is "Env". Env contains one or more agents. Each agent contains inst of Sequencer, driver, monitor and config. config indicates if it'a active agent (i.e TX => all seq, driver, monitor implemented) or passive agent (i.e RX => only monitor implemented)
All above components are created using class.
class sequencer extends base ... endclass
class driver extends base ... endclass
class monitor extends base ... task monitor(bit[3:0] ..) forever begin ... end endtask endclass
interface pds_if(input ...) .. endinterface

//PDS UVC => top level uvc which inst all of the above components
class pds_vc extends base; ... endclass

On top of this, scorboard UVC is also added to tb, so that i/p and o/p to/from DUT can be compared and errors flagged.  
UVM phases: (pg 177 of UVM doc from cadence) These are predefined phases. User defined phases can also be added. Phases start running in the order below when global task run_test() is called.
NOTE: to use phases below, we simply declare *_phase function in your class, and add reqd functionality. We should not call *_phase directly. It's automatically executed by simulator during that phase.
 - build_phase => building testbench. All hier should be built using build_phase rather than constructors. build_phase executes top down, all other phases execute bottom up.
 - connect_phase => making connections. Any connections b/w components should be made using connect_phase rather than constructors
 - end_of_elaboration_phase => for any pre run activity
 - run_phase => simulation of design. run_phase is implemented as a task, as it can consume time. Rest all phases are implemented as functions, as they run in 0 time. run_phase has many subphases and were added in UVM1.0. These sub-phases run in parallel with run_phase.
 - check_phase, report_phase => checking results and generating reports
 
----------------------------
Built in classes (chapter 4 in uvm book)
---------
UVM lib has many inbuilt classes from which we extend to create our classes. Ex:
1. uvm_object: this is the base class for all (data and component) UVM classes. It has built in methods for copy(), compare(), clone(), print(). Most of the time, we derive our data item from uvm_sequence_tem which itself extends from uvm_transaction which extends from uvm_object.
 ex:
class apb_transfer extends uvm_object; //or "extends uvm_sequence_item"  can also be used
      ...
  `uvm_objects_utils_begin(apb_transfer) //uvm automation macros => used to declare common operaations
     `uvm_field_int(addr, UVM_DEFAULT)
  `uvm_objects_utils_end
  function new (string name = "apb xfer"); //uvm construction new() - not mandatory
   super.new(name);
  endfunction
endclass

2. uvm_component: All infrastructure components as testbench comp, UVCs, tests are derived directly or indirectly from uvm_component. Typically we derive our user classes from methodology classes (uvm_agent, uvm_driver, uvm_sequencer, uvm_monitor, uvm_scoreboard, uvm_test and so on), which are themselves extension of uvm_component. Phases and configuration methods are functionality provided by uvm_component base class.
ex:
class testbench_comp extends uvm_component; //testcase
  function new(string name, uvm_component parent)
   super.new(name,parent);
  endfunction
  function void build_phase(uvm_phase phase);
   super.build_phase(phase);
   my_uvc = if_comp::type_id::create("my_uvc", this);
  endfunction
  //similarly other function for end_of_elaboration_phase, etc can be added here
  task run_phase (uvm_phase phase); //this is where the testcase is coded and run
   ...
  endtask
endclass

class if_comp extends uvm_component; //this is some other class that has many uvm_phases
 function new ... endfunction
 function void build_phase ... endfunction
 task run_phase ... endtask
endclass

module test; //testbench to run above testcase
 testbench_comp tb;
 initial begin
  tb = testbench_comp::type_id::create("testbench", null);
  run_test(); //this call starts the uvm phases for all the classes above
 end
endmodule

-----------------
contraints:
-------
In any class, we can have constraints defined for any field.
ex: constraint c_addr {addr[1:0] == 2'b01; }

we can overwrite any constraint in subclass, by redeclaring. Parent class contraint can be removed in subclass by leaving it empty.
ex: constarint c_addr {} => constraint c_addr is removed for this subclass, even though it's present in parent class.

-----------
coverage in uvm: see system verilog notes also:
----------

Metric driven verification
1. functional coverage
2. assertions (static formal verification and sims)
3. directed tests
4. code coverage

Most coverage constructs are placed in monitors.

1. functional coverage of 2 types:
A. assertions for control oriented coverage => cannot be in class
ex:
property req_gnt (cyc);
 @(posedge clk) req |=> ##[cyc] gnt;
endproperty

cover property (req_gnt(3));
cover property (req_gnt(4));

B. covergroups for data-oriented coverage => can be declared as class member
ex:
covergroup cg @(posedge clk);
 len: coverpoint pkt.length { ...}
 addr: cross pkt.addr, len;
endgroup

cg cg1 = new();

--------------

Details

Published: Friday, 12 October 2018 04:52

Hits: 1473

ARM: It was initially called Advanced Risc Machines Ltd, but later changed the name to ARM Ltd. It licenses CPU cores (cortex lineup), as well as GPU cores (mali lineup). NOTE: ARM primarily licenses processor cores, and NOT microprocessor or microcontroller. However, they also provide licences at system level and software level for companies which want to get the full pkg. It's cores can be used anywhere, although they are mostly used in microcontrollers. It licenses these designs (core license), as well as it allows companies to license it's instruction set (architectural license), so that they can build their own design any way they like. Apple and Qualcomm use architectural license from ARM to design their mobile processors. For Core licenses, companies receive ARM synthesizable core IP in verilog (i.e processor RTL). These IP are called soft IP, as they are in RTL. Synthesis and PnR are carried out by the companies getting these licenses.

ARM was formed in 1990, and introduced ARM6 processor family in 1991. It was based on ARM v4T processor architecture. Then came ARM7, which were still based on v4T, most popular of which was ARM7TDMI. ARMv5E arch was introduced with ARM9E processor families (E stands for enhanced, which added DSP inst for multimedia processing). Then came the ARM11 processor family based on v6 arch. At this time, it was decided to branch processor families into different types, based on their use profile. Also, each processor family would be based on arch most suited for that application type. This resulted in new product portfolio from ARM called cortex family of processors.These were subdivided into 3 profiles based on application usage. The 3 profiles were A, R, M (discussed later). New v7 arch was introduced for the cortex family. Each of these profiles had their own tailored arch, namely v7-A, v7-R and v7-M.

Though ARM had it's classic cores starting from 1990's, it's more popular "cortex" cores started appearing from 2004. These are the cores that you see everywhere in designs, the classic cores (ARM6, ARM7, etc) were used in older devices, and have disappeared from mass market. One reason for success of ARM cortex lineup is that they became very cheap, with some cortex M0 based microcontrollers sold for as low as 25 cents. This allowed these 32 bit cores to replace 8 and 16 bit microcontrollers. Let's talk about ARM ISA before delving into profiles and arch.

Details

Published: Friday, 12 October 2018 04:51

Hits: 1916

VNC: Virtual Network Computing

VNC is a graphical desktop sharing system, used to remotely control another PC. It's same as other software as chrome remote desktop,  TeamViewer, , etc which allow you to control remote PC. VNC is very popular among enterprises, and is open source under GNU license. VNC was orinally developed in UK. Many other commercial or open source products based on VNC original source code developed. In 2002, VNC R&D center was closed. It's developers formed RealVNC which developed open source as well as commercial product under the same name. Most of the time when people say VNC, they mean RealVNC.

Intro material on Wiki: https://en.wikipedia.org/wiki/Virtual_Network_Computing

VNC server/client model:

VNC software has 2 parts: a sever software, and a client software. You install server software on the desktop which you want to control. You install client software on the desktop from where you want to control. The client software knows how to connect to server software. The client software displays the desktop screen on remote desktop which is running the server software for VNC.

Installation:

Install RealVNC from here: You will need to install both RealVNC server and RealVNC client. They will need to be installed on different computers. Server on the computer to be controlled, and client on the computer that controls the server computer. Choose appropriate OS and then download it.

Real VNC server: https://www.realvnc.com/en/connect/download/vnc/

RealVNC client: https://www.realvnc.com/en/connect/download/viewer/

Running VNC:

Once installed, you can start VNC server on server desktop by clicking on RealVNC icon or typing "vncserver" on terminal. Once started, VNC server always starts on powerup. OWhen vncserver is running, it shows the ip address for the computer on which it is running. It's something like this kind of message:

$vncserver

......

New desktop is raspberrypi (192.168.1.109)

....

Now on the client machine (where you have the VNC client software installed), you enter this number in address section (here, it's 192.168.1.109). Once enetered, it brings up an icon, on which you click, and you can see the remote desktop screen (where VNC server is running). Now if you work on this screen, it seems as if you are directly working on the remote desktop (the screen refreshes amazingly fast. Keystrokes from client to server, as well as pixels from server to client are transmitted pretty fast, especially if both client and server are connected to high speed internet).

vncserver command on Linux terminal can be used with a lot of options to set the display options. One helpful option is:

vncserver -geometry 2560x1024 -depth 24

NOTE: that when we say display, we mean the physical screen that is on the monitor of remote desktop. However, the pixels of that display are stored in memory, and the monitor is just displaying whatever is stored in that memory. So, we can have another display which has pixels stored in memory only and doesn't go to any monitor. This is called a "virtual display". VNC allows these virtual displays to be created on the server machine, and then be accessed using VNC viewer. Thus we can have 10's of display on a single server desktop, where one of them is real display connected to physical monitor, while all others are all virtual displays.

Headless servers or servers which don't have any monitor connected, don't start the gui program for the display. In such cases, VNC server has nothing to display since it always shows the physical display by default. So, in turn VNC server program doesn't start at startup. in such cases, we start VNC server by logging into the server machine via ssh. Then VNC server creates a virtual display and this virtual display can be seen via a VNC client.

On the top center of VNC session, we have a way to kill VNC or set many options. Look thru them, if you need to set anything else.For ex, if you have 2 monitors, and it's not working, try setting "UseAllMonitors to true" over there.

NOTE: we have .vnc dir in the home dir. Inside this dir, is a config file, which controls how the vnc desktop should look. To get full screen extended on desktop,  we add these lines to config file, so that we don't have to type it every time on cmd line:
-geometry 2560x1024
-depth 24

Guest Access: In VNC, allowing guest acces to others is easy. Steps:

• Run "vncconfig &" on cmd line. This cmd has to be run on lindesk terminal and not on lsf terminal
• On pop up box, click commands->options. On new pop up box, choose advanced.
• Change guest access to "Interactive" and click apply.
• On main pop-up box, if we click on options, we should see a "tick mark" on Guest Login. If not, tick that by clicking.
• Now, anyone can connect using login "guest" and no password.
• When user requests access, a new box appears on bottom. click on "accept" to allow guest access to your vnc m/c.

Putty:

 If we are on a windows machine, and don't have terminal to connect to, we can use a program called Putty, that supports a lot of protocols as ssh, ftp, etc. It has a GUI interface, and is a lot easier to use.

First download Putty. Then Use Putty to SSH to the above machine. That brings up a terminal on remote machine to which you work in usual way. When done, log out of Putty and close the window.

-----------------------------------------------------

ALL JUNK BELOW. NEED TO MOVE ELSEWHERE FIXME ???

LSF:

Any jobs can now be run only in lsf machine. So open xterm on lsf
Open Xterm on an LSF machine: bsub \-Is \-R "linux&&bit64" "xterm" & => OBSELETE
Open Konsole on an LSF machine: bsub \-Is \-R "linux&&bit64" "konsole" & => OBSELETE
Open Konsole on an LSF machine on RHEL6 OS: bsub \-Is \-R "select[ws60]" "konsole" & => use ws40 for RHEL4 (ws60 is latest). ws60 provides latest AME tools.
Open Konsole on an LSF machine on SUSE11 OS: bsub \-Is \-R "select[sles11]" "konsole" & => this was needed to get latest AME tools, but not anymore. SUSE not used anymore
Run <tool_name> -ame on both OS to see which gives you latest tools. Some newer versions may be avilable on 1 OS and not on other.

OS for Artisan:
Artisan 5.2.1 and earlier will only run on the legacy SuSE11 OS.
Artisan 5.3 will run on both SuSE11 and RHEL6.
The upcoming Artisan 5.4 will only run on RHEL6.

Run icfb on suse m/c: bsub -R "select[sles11]" -Is icfb -artisan-2.91p1 &

NOTE: to get around check and save issues, run icfb on suse m/c: icfb -artisan-5.2.1


For LSF jobs submitted, if we want to know what OS job got submitted on, look in the log file (i.e irun.log) to find name of lsf m/c. Then run:
ex: /home/kagrawal/ > lshosts machine1.com => last 2 RHS entries show OS

HOST_NAME      type    model  cpuf ncpus maxmem maxswp server RESOURCES
dlewz2732.d LIN_X64 p4x_3400 417.0    12 262047M 262145M    Yes
(bit64 cs dc X64 linux srvClass01 maxmem32G linux26 maxmem64G p4x maxmem128G warm maxmem256G sles suse sles11p2 !sles11) => OS is sles11.2
#Preventing jobs from getting killed in lsf:
jobexclude --add <jobid> => to add a job
jobexclude --list => to list all added jobs


#snapshot
In any dir, there is .snapshot dir, within which is there are dir with timestamp. Just cd into appr dir, and cp stuff that is to be retrieved.

dssc cmds:
---------
dssc -help => lsits all options
dssc <cmd_name> -help => lists syntax of a specific cmd

checkin:
checkin for 1st tme: dssc ci -new <file/dir> -com "comments_here" -rec => -rec needed for recursive
checkin a file after editing with lock: dssc ci <filename>
dssc ls -report status -rec => shows revs of all checked out files/dir (current rev vs .)
dssc diff "file1.v" "file1.v;Latest" => diffs b/w current modified checked out file against one in repository.
dssc retire -force => to completely remove it from database.
dssc ci -new <file/dir> -skip => use ci with -skip after retiring a file in db. Else, old retired file will be checked in.

checkout:
checkout all files recursively in read mode: dssc pop -rec => does it starting from current dir
checkout a file in readmode: dssc co <filename>
checkout a file in editmode with lock: dssc co -lock <filename>
checkin a file after editing with lock: dssc ci <filename>

dssc cancel:
dssc cancel -force <filename> => this is to cancel checked out file (even with edits), and to repop with original version.
checkout a file in editmode without lock: dssc co -get <filename> => This gives unlocked copy which can be modified. Do a chmod to 664 or 755.
Then to populate the original file (and discard the current modified file), do:
dssc pop -force <filename>
dssc unlock <filename> => To unlock files (i.e remove lock). This can be useful when files can't be checked out or something else gone bad.