LinkedIn Top Voice | TEDx Speaker | Samsung (SSIR) | Ex - Intel | ASIC Verification | Proficient in SV, UVM, OVM, SVA, Verilog | Functional Safety ISO 26262 Level 1 Certified | Speaker at Engineering Colleges |
Both RTL design and Verification needs to go through a series of steps to make an IC product ready and bug free. Some of the steps are mentioned below: ✓ RTL Design: [1] To understand the Microarchitecture specification thoroughly and to prepare the Design Document to understand the features and working of the block in depth. [2] To write RTL code either in VHDL or Verilog or SystemVerilog as per the requirement for each different module. [3] Bind all the respective module and instantiate them at the top module and to make ensure that all the port connections are proper. [4] To follow all the coding guidelines and make sure the design is synthesizable and to generate the netlist. [5] To write assertions and assumptions coding at microarchitecture level for the respective design block. [6] To perform STA analysis to check whether any timing issues are there within the design and to ensure all the timings are met within the design. [7]To perform Lint analysis within the design to check for any floating and hanging wires and signals and also perform CDC(Clock Domain Crossing) analysis. [8] To add any additional features of the design changes and accordingly coded and modify the design. ✓ Asic Verification: [1] To understand the Design Specification and its functionality, involved in Feature Extraction, identify the Test Scenarios, I/O Port List. [2] Prepare the Verification Plan which will involve all the metrices of the Verification.Involves the Testbench Architecture, UVC Description, Reference Model, Checkers and the Verification Flow. [3] Preparing the TestPlan, identify the Directed and Corner case scenario.The Plan can be subdivided into Functional Test Cases, Connectivity Checks, Data and Control Path Checks, Register Testing, etc. [4] Start Coding the UVC's and when a basic Testbench Infrastructure became ready, verify it with a Sanity TestCase. [5] Code the Scoreboard and there are multiple ways to do it either with tlm analysis fifo, set of queues and arrays, imp macros, etc. [6] Use the Configuration wisely and start with coding more Test Scenario extending from Base Test or a library of Sequences. [7] Prepare a Bug Rate Chart and usually at the initial level Bugs can be caught with the Directed Testcase.But once the Bugs start dropping it's the time to introduce Corner Cases, Functional Coverage and Assertions. [8] Start Prepare a Assertion plan and initiate Functional and Code Coverage.Code Coverage will let you know how much Code has been exercised and Functional Coverage will deal with the Functionality. [9] Identify the coverage Holes and write more Testcases to cover the loopholes.Implement Checkers which are inbuilt in Assertions and it will help more in Verification. [10] When the Coverage goal achieved launch the GLS (Gate Level Simulation) which is generated over the netlist. #vlsi #asic #engineering #electronics
CFBR
Informative 😊
CFBR
Informative
Knowledge || Progress || Transform<->Time || Acknowledge by Nature Around
11moCFBR +As verification engineer add on randomisation scenarios with multiple seeds and negative scenarios to break the design and find missing things in the specification… A verification engineer should not just follow specification provided by in-house design team … Verification engineer should follow superset of protocol interfaces used specification to throughly check all protocol related features compliance also present.. That’s why no. Of verification engineers > designer in a project GLS -> majorly focus on PG netlist GLS …that’s the final product …