Author: (\/)@{-}!
•5:55 AM



Much of System Verilog is intended to be Synthesizable


Author: (\/)@{-}!
•4:59 AM
 Tasks and Functions helps the designer to break up large behavioral designs into smaller pieces. The designer has to abstract the similar pieces in the description and replace them either Functions or tasks. This also improves the readability of the code, and hence easier to debug. 

Functions :

  • Keywords:  function , endfunction 
  • Can be used if the procedure
    • Does not have any timing control constructs ; i.e Must execute in Zero-Time.
    • Returns exactly a single value
    • Has at-least one input argument declaration
       Syntax: 
              function   <range_or_type>   function_name;
                       input_port_declaration (s) ;
                       local_variable_declaration (s) ;
                       statement_or_block
                       function_name = (expression);
              endfunction 
       
       Example : 01: Parity Generator
            module   parity;
                  ....
                  reg [31:0] addr;
                  reg parity;

                 initial  begin
                          …
                 end
                 always @(addr)
                     begin
                         parity =  calc_parity(addr);
                         $display("Parity calculated = %b",     calc_parity(addr) );
                     end
                 function calc_parity;
                        input [31:0] address;
                        begin
                            calc_parity = ^address;
                        end
                 endfunction
            endmodule

      Example : 02: Controllable Shifter
           module shifter;
                `define LEFT_SHIFT      1'b0
                `define RIGHT_SHIFT     1'b1
                  .......
                 reg [31:0] addr, left_addr, right_addr;
                 reg control;

                 initial
                    begin
                          …
                    end
                always @(addr)
                    begin
                       left_addr  = shift (addr, `LEFT_SHIFT);
                       right_addr = shift (addr,`RIGHT_SHIFT);
                    end

                function [31:0]  shift;
                         input [31:0] address;
                         input control;
                         begin
                            shift = (control==`LEFT_SHIFT) ?(address<<1) : (address>>1);
                         end
                endfunction
            endmodule


 Tasks:

  • Keywords: task, endtask 
  • Must be used if the procedure has
    • any timing control constructs ; i.e @( ..) , #delay , wait  e.t.c
    • zero or more than one output arguments
    • no input arguments
      Syntax:
             task task_name ;
                    port_declaration (s);
                    local_variable_declaration (s);
                    statement_or_block;
             endtask
  
      Example : 01: Use of input and output arguments
             module operation;
                   parameter delay = 10;

                   .......
                   reg [15:0] A, B;
                   reg [15:0]  AB_AND, AB_OR, AB_XOR;
 
                   initial
                      $monitor( …);
         
                   initial
                      begin
                          …
                      end

                  always @(A or B)
                     begin
                          bitwise_oper(AB_AND, AB_OR, AB_XOR, A, B);
                     end

              
                  task bitwise_oper;
                       output [15:0]  ab_and, ab_or,  ab_xor;
                        input [15:0] a, b;
                        begin
                            #delay 

                                        ab_and = a & b;
                                        ab_or = a | b;
                                        ab_xor = a ^ b;
                        end
                  endtask
            endmodule


       Example : 02 : Use of module local variables
            module sequence;
               .....

               reg clock;

               initial
                 begin
                     …
                 end

               initial
                  init_sequence;


               always
                  asymmetric_sequence;


               task init_sequence;
                  clock = 1'b0;
               endtask

               task asymmetric_sequence;
                   begin
                      #12 clock = 1'b0;
                      #5  clock = 1'b1;
                      #3  clock = 1'b0;
                      #10 clock = 1'b1;
                  end
               endtask
          endmodule
  

Difference between Tasks and Functions 

  • A function can enable (call) just another function (not task) ; A task can enable other tasks and functions.
  • A function execute in 0 simulation time ; A task can execute in non-zero simulation time.
  • A function no timing control statements allowed ; A task may contain any timing control statements
  • A function must have at-least one input argument ; A task can have arbitrary input, output, or inout
  • A function return only a single value ; A task do not return any value
  • Tasks and Functions are defined in a module 
  • Tasks and Functions are local to the module
  • Tasks and Functions can have local variables (registers, but not nets) and events
  • Tasks and Functions contain only behavioral statements
  • Tasks and Functions do not contain initial or always statements
  • Tasks and Functions are called from initial or always statements or other tasks or functions. 
  • Functions are purely combinational , typically used for conversions and commonly used calculations ; Tasks can be used for common Verilog code.
Author: (\/)@{-}!
•11:43 AM

How to generate coverage in VCS (SNPS) , QUESTA and NC

MODELSIM or QUESTA:

STEP1:  Compile your design files with your selected coverage
              QuestaSim  >  vlog  +cover  <bcst>   -f  design_file_list
               +cover [=s b c e f t x]   Enable code coverage metrics by specifying one or more of the characters:
                             s - Statement
                             b - Branch
                             c - Condition
                             e - Expression
                             f  - Fsm
                             t  - Toggle
                             x - Extended toggle
                           Note:  If no character is specified, sbceft  is the default. 

STEP2:      Simulate with the coverage option
                  QuestaSim > vsim  -coverage file_testbench.v
                  and the    run   -all 
         OR, 
                  You can enable it using GUI Mode also.
                  
                  Go to  Compile  >  Compile Options and select the Coverage tab.Another option is,you have to just right-click on your design file at "Project" and choose "Properties". Now, you can see coverage tab. After running the simulation and you will be able to see the coverage tabs for analysis.
                  
                   If you are running regression and you have to save the coverage report of the first test (UCDB file) and merge to the next UCDB of the next test till the regression finishes.And finally you will be able to the  see total Code Coverage.
                  
                   vsim   -c  -do  "coverage  save -onexit  <TESTSET_CODE_COVER>.ucdb ; run -all;exit"  -coverage  -voptargs="+cover=bcfst"  <otherOptions>  <TOP>
Here we tell vsim  to
    1.  Enable code coverage (-coverage),
    2.  The types of coverage to collect (via
 -voptargs=+cover= bcefst").
    3.  To produce a coverage database file on the exit of simulation  (do "coverage save -onexit coverage.ucdb)
    4.  Continue the step1 and Step2 till the regression ends

STEP3:
            Further if you have multiple coverage databases, you can merge them into a single database by using:
                vcover  merge <ucdbFile1>.ucdb   <ucdbFile2>.ucdb  ...  <ucdbFileN>.ucdb   <ucdbFileResult>.ucdb

         
            The finally you can generate a HTML report:
               vcover report  -html  -htmldir  <dirToOutput>  -verbose  -threshL 50  -threshH 90  <ucdbFileResult>.ucdb


NC SIM
ncverilog  <OTHER_ARGUMENTS> +nccoverage+all +nccov58 +nccovworkdir+cov_work +nclexpragma +nccovtest+<testcase_name> +nccovoverwrite +nccovdut+worklib.dut_top -T test_top.sv

1. For switching coverage ON :  Use +nccovfile+dut_cov.txt  while compiling.    //*********************dut_cov.txt****************//
          select_coverage -all -module top
             .......
          select_functional
          select_fsm

    //************************************************//
Note : During simulation use : covoverwrite  -covtest mycov.cov

2. To view coverage:
         iccr -keywords+detail iccr1.cmd        OR
         iccr -keywords+summary iccr2.cmd   OR
         iccr -keywords+dontmerge iccr3.cmd
       
       //********************* iccr1.cmd **********************//
          merge cov_work/design/test* -output merged_dir
          reset_coverage
          load_test cov_work/design/merged_dir                                                                                                    report_detail -instance -betsafd -cgopt top... > detail.rpt
     
      //********************* iccr2.cmd **********************//
          merge cov_work/design/test* -output merged_dir 
          reset_coverage
          load_test cov_work/design/merged_dir                                                                                                    report_summary -instance -cgopt top... > summary.rpt 

      //********************* iccr3.cmd **********************//
          load_test cov_work/design/*
          report_summary -instance -cgopt top... > summary.rpt


VCS

1.  To generate functional coverage
      % urg -dir simv.vdb

2.  To generate code coverage
     % vcs -cm_pp -cm_dir simv.cm  -cm_name  XXX  -cm_report summary
Author: (\/)@{-}!
•10:31 AM
An interface encapsulate a group of inter-related wires, along with their directions (via mod-ports) , synchronization details (via clocking block) , functions and tasks. The major usage of interface is to simplify the connection between modules. 

But Interface can't be instantiated inside program block, class (or similar non-module entity in System Verilog). But we needed to be driven from verification environment like class. To solve this issue virtual interface concept was introduced in System Verilog.

A virtual interface is just a pointer to a physical interface. i.e. Virtual interface is a data type (that implies it can be instantiated in a class) which hold reference to an interface (that implies the class can drive the interface using the virtual interface). It provides a mechanism for separating abstract models and test programs from the actual signals that make up the design. Another big advantage of virtual interface is that class can dynamically connect to different physical interfaces in run time.
Example :
                       
             interface  ahb_vip_intf ; 
                  
 ................ ;

                   ................ ;             
            endinterface 

         

            class AHB_driver ;
                virtual ahb_vip_intf  intf;
                functional new(input virtual ahb_vip_intf intf);
                        this.intf = intf;
                endfunction
              
               task main() ;
                   intf.sig1 =1;
                   ........ ;
               endtask
          endclass
Author: (\/)@{-}!
•8:04 AM

                                                               Asic Design Flow                                                    

Step 1: Prepare an Requirement Specification
Step 2: Create an Micro-Architecture Document.
Step 3: RTL Design & Development of IP's
Step 4: Functional verification all the IP's/Check whether the RTL is free from Linting Errors/Analyze whether the RTL is Synthesis friendly.
  • Step 4a: Perform Cycle-based verification(Functional) to verify the protocol behaviour of the RTL
  • Step 4b: Perform Property Checking , to verify the RTL implementation and the specification understanding is matching.
Step 5: Prepare the Design Constraints file (clock definitions(frequency/uncertainity/jitter),I/O delay definitions, Output pad load definition, Design False/Multicycle-paths) to perform Synthesis, usually called as an SDC synopsys_constraints, specific to synopsys synthesis Tool (design-compiler)

Step 6: To Perform Synthesis for the IP, the inputs to the tool are (library file(for which synthesis needs to be targeted for, which has the functional/timing information available for the standard-cell library and the wire-load models for the wires based on the fanout length of the connectivity), RTL files and the Design Constraint files, So that the Synthesis tool can perform the synthesis of the RTL files and map and optimize to meet the design-constraints requirements. After performing synthesis, as a part of the synthesis flow, need to build scan-chain connectivity based on the DFT(Design for Test) requirement, the synthesis tool (Test-compiler), builds the scan-chain.

Step 7: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT) after synthesis.
  • Step 7a: Perform the Netlist-level Power Analysis, to know whether the design is meeting the power targets.
  • Step 7b: Perform Gate-level Simulation with the Synthesized Netlist to check whether the design is meeting the functional requirements.
  • Step 7c: Perform Formal-verification between RTL vs Synthesized Netlist to confirm that the synthesis Tool has not altered the functionality.( Tool: Formality )
  • Step 7d: Perform STA(Static Timing Analysis) with the SDF(Standard Delay Format) file and synthesized netlist file, to check whether the Design is meeting the timing-requirements.( Tool: PrimeTime)
  • Step 7e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement.
Step 8: Once the synthesis is performed the synthesized netlist file(VHDL/Verilog format) and the SDC (constraints file) is passed as input files to the Placement and Routing Tool to perform the back-end Actitivities.

Step 9: The next step is the Floor-planning, which means placing the IP's based on the connectivity,placing the memories, Create the Pad-ring, placing the Pads(Signal/power/transfer-cells(to switch voltage domains/Corner pads(proper accessibility for Package routing), meeting the SSN requirements(Simultaneous Switching Noise) that when the high-speed bus is switching that it doesn't create any noise related acitivities, creating an optimised floorplan, where the design meets the utilization targets of the chip.
  • Step 9a : Release the floor-planned information to the package team, to perform the package feasibility analysis for the pad-ring .
  • Step 9b: To the placement tool, rows are cut, blockages are created where the tool is prevented from placing the cells, then the physical placement of the cells is performed based on the timing/area requirements.The power-grid is built to meet the power-target's of the Chip .
Step 10: The next step is to perform the Routing., at first the Global routing and Detailed routing, meeting the DRC(Design Rule Check) requirement as per the fabrication requirement.

Step 11: After performing Routing then the routed Verilog netlist, standard-cells LEF/DEF file is taken to the Extraction tool (to extract the parasitics(RLC) values of the chip in the SPEF format(Standard parasitics Exchange Format), and the SPEF file is generated. ( Tool: STARRC )

Step 12: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT/DRC/LVS/ERC/ESD/SI/IR-Drop) after Placement and Routing step.
  • Step 12a: Perform the Routed Netlist-level Power Analysis, to know whether the design has met the power targets.
  • Step 12b: Perform Gate-level Simulation with the routed Netlist to check whether the design is meeting the functional requirement .
  • Step 12c: Perform Formal-verification between RTL vs routed Netlist to confirm that the place & route Tool has not altered the functionality.
  • Step 12d: Perform STA(Static Timing Analysis) with the SPEF file and routed netlist file, to check whether the Design is meeting the timing-requirements.
  • Step 12e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement, Peform the Fault-coverage with the DFT tool and Generate the ATPG test-vectors.
  • Step 12f: Convert the ATPG test-vector to a tester understandable format(WGL)
  • Step 12g: Perform DRC(Design Rule Check) verfication called as Physical-verification, to confirm that the design is meeting the Fabrication requirements.
  • Step 12h: Perform LVS(layout vs Spice) check, a part of the verification which takes a routed netlist converts to spice (call it SPICE-R) and convert the Synthesized netlist(call it SPICE-S) and compare that the two are matching.
  • Step 12i : Perform the ERC(Electrical Rule Checking) check, to know that the design is meeting the ERC requirement.
  • Step 12j: Perform the ESD Check, so that the proper back-to-back diodes are placed and proper guarding is there in case if we have both analog and digital portions in our Chip. We have seperate Power and Grounds for both Digital and Analog Portions, to reduce the Substrate-noise.
  • Step 12k: Perform seperate STA(Static Timing Analysis) , to verify that the Signal-integrity of our Chip. To perform this to the STA tool, the routed netlist and SPEF file(parasitics including coupling capacitances values), are fed to the tool. This check is important as the signal-integrity effect can cause cross-talk delay and cross-talk noise effects, and hinder in the functionality/timing aspects of the design.
  • Step 12l: Perform IR Drop analysis, that the Power-grid is so robust enough to with-stand the static and dynamic power-drops with in the design and the IR-drop is with-in the target limits.

Step 13: Once the routed design is verified for the design constraints, then now the next step is chip-finishing activities (like metal-slotting, placing de-coupling caps).

Step 14: Now the Chip Design is ready to go to the Fabrication unit, release files which the fab can understand, GDS file.

Step 15: After the GDS file is released , perform the LAPO check so that the database released to the fab is correct.

Step 16: Perform the Package wire-bonding, which connects the chip to the Package.

                                                          (\/)@{-}!