Shades of Pacific...

Register verification in ASIC

The Register space in any ASIC is very important part for design as it provides the only means to configure and monitor the status of various processes that happen inside the ASIC The numbers of such register has been increase in step with the increase in the complexity of the ASICs to the tune that you could have millions of registers in some ASICs.. There are individual set of register & containers (array of same register). Each register have their own type (write-read, read-only), Reset values, fields etc these registers are replicated in ASIC no of times with unique address depending upon module instantiates.

Functioning of an ASIC highly depends on this registers. They are the nuts and bolts communication with firmware. Ensuring that the register work exactly as intended is one most important and challenging tasks in ASIC Verification.

In order to verify this registers efficiently one of the techniques employed is to create accurate Register Database in spirit format. Spirit Register Database is commonly used in industry because of the ease it extends to parse and convert to any language code for verification. We are using this to parse into system verilog language (OVM/UVM Register package) for our ASIC verification and same package is used to generate different language code bases (C++, Verilog, Etc).

Challenges for Register Verification:

• The Register space in any ASIC is very important block.
• ASIC’s contain lot of registers.
• Different type of Register (Status, Control Etc) & Array of registers.
• Replication of same set of Register space.
• All the aspects of Registers RTL Implementation should be verified properly.
• Functional coverage of all the fields of each register can be used as one of the parameter for verification closer.

OVM/UVM Register package help us to overcome all above mentioned challenges and have a below mentioned benefits.

• Use this Register package (Register Database SV class) as Reference Model, Stimulus generator or scoreboard in Verification environment.
• Single point modification will reflects in whole verification environment.
• Verify all aspects of registers(type, reset, fields, reserve area).
• Verifies Register using backdoor operations.
• Get the functional coverage of all registers and their fields.
• Use full to generate other language code for same register database.

Module Level Verification of Subsystem

While doing System Level Verification we need to make sure that every part of system as well as Integration between the peripheral and processor should be verified properly. In order to verify that subsystem (ARM/DSP) and their integration we try to cover almost all the possible test scenarios using Verification Plan but still some part of System remain unverified & That will be resolved by using Module Level Verification of Processor Subsystem.

Let me First talk about System Level Verification Environment,

SOC (system on chip) functionality is controlled by subsystem (DSP, ARM etc).Some Complex SOC has more then one subsystem inside the chip & different IP (peripherals) which executes functionality(Serial port, Audio video coded, Camera Etc) . These subsystems control peripherals inside the chip & execute functionality of peripherals. So, here we need to verify every IP (peripherals) individually and their integration with subsystems and other peripherals.

There are two type of verification we are using to verify entire SOC (System of chip).

(A) Module Level verification

This Type of Verification used to verify module or IP individually.

IPs (peripherals) mostly controlled through input pins. We provide set of input and checking the functionality & expect desired results on output pins according to IPs specifications. In this process we are checking DUT (Design under test) behaviour by providing different type of Test scenarios using Constraint - Randomization and make sure that Module or IP is fully verified by checking Coverage (Functional & Code) Coverage.

We mostly use System Verilog, e, OVA, and VHDL/verilog languages for this type of verification.

(B) System (Chip) Level verification

This type of verification helps us to verify SOC integration between different peripherals, between two subsystems, between subsystem and peripherals & functionality of entire SOC.

Functionality of SOC is controlled by Processor subsystems (DSP, ARM etc) not by inputs only. These subsystems read instruction from the program memory and executes. All peripherals are connected with subsystems and controlled though System Bus or Bridge. Now we load set of instructions (to be executed for specific functionality) inside program memory of subsystems & it executes these set of instruction & SOC function accordingly.

We mostly use C, Assembly language for this type of verification.

we write Test case in C language to execute various functionality from Processor and assembler converts C language into Assembly language. So, The Assembler reads functions & macros from C Test case and selects set of Assembly instructions and prepare entire test case in Assembly instructions. Now these instructions get converted into binary language because we can load these binary data into program memory.

Once we load data into program memory we run entire design & this verification also has a test bench which has BFM (Bus function module), Loop back & other complimentary logic through which we validate this design by checking test case pass or failed.

Above is normal verification methodology which we are using to verify system on chip. This covers all the functionality of design.

So, why we need Standalone module level verification for Processor Subsystem?

Processors has own set of instructions & how to make sure all instruction get executed in System Level Verification?

In System level verification environment we are using Assembler which converts C Program into Assembly. So, we highly rely on assembler which has hard coded set of instructions for any functions. It uses Limited instructions or Set of instructions.

Assemblers designed only once by vendor and normally it has same set of instructions for C functions & macros.

There are other instructions also though which we can check functionality. Those instructions are not used by assembler. That way we can verify all the functionality of the design but still not verified all the instructions of Processor.

To test every instruction we have to modify the Assembler which is time consuming & also it’s difficult because by modifying it still we cant be sure of using all the instructions in assembler and again not much relevant to system level verification.

We provide Clock & Reset from Test bench and once Processor come out from Reset it start executing functionality according to given instructions & write test case in Assembly language by using all different kind of instructions & check All functionality again. So, here we don’t require assembler and we make sure that 100% coverage achieved by processor.

To execute any functionality through this module level environment, take less time & resource compare to system level.

Above mentioned figure shows the environment of Processors module Level verification. We write test case in Assembly language using all possible functionality related instructions & Assembly language is getting converted into binary format.

Now all instructions get into binary format which is now ready to load into program memory by using preloading option into test bench.

This verification environment does have its own linker file, test macros & Test bench.

Linker file which specifies the program memory location where Processor read instruction & execute also take care of jump kind of instruction where user want their program should execute from different memory locations.

Test bench at top-level which has memory pre-loading, BFM & loop back kind of functionality to verify Processors.

Conclusion:

During SOC Verification we target 100% code coverage & functionality coverage by using Module level & system level verification.

We always close our verification process once we verify all functionality but still in System like DSP/ARM remain unverified as we haven’t tested all instructions yet

Instructions are very crucial for any Processor & it’s like blood in a vein. We can’t afford to ignore it in any SOC Projects as Verification Engineer.

The Leadership

I always admire great leaders of History & some leaders of today's generations irrespective of which side they are right or left(Wrong) but i really look up to them

and try to learn from their stories & interviews.

i work in a software firm & my previous organisation we working on one of the good project and client was happy with our work but as a professional we were not feeling satisfied because during project we were not be able to learn new technology.so,we went to our manager expressed our concern & conversation heated up manager said "SOME HOW I HAVE TO RUN THE SHOW".personally i didn't like this attitude i understand there are constraint for manager but he should have conveyed the same massage different way.Here i found the difference between Manager & Leader.

Lord Ganesha is great symbolic leader ship icon in India & Look at the picture above Leader should have quality like that.Few points i would like to add here...

Big Head: Long range thinking power

Small but sharp Eyes: Leader should see pain point of every followers

Large Ears: He should listen to even a small followers

Big stomach: Able To digest Everything & any kind of conditions remain strong in front of followers.

Half Tooth & Full Tooth :Half tooth symbolise that Leader Might not know the minor detail of subject/problem but second full tooth symbolises willingness to resolve a problem.Leader may not have in depth knowledge of subject but willingness to resolve issue is necessary.

To be a great leader requires to have above mention quality other wise they end up being manager & in future i would like to be known as good leader rather then a Manager.

Recently i came across a nice conversation between Mr. Narayana Murthy A great leader of my generation ,i always look up to him for inspiration & spiritual guru Mr Deepak chopra.It was about Leader ship & success.

Please check this conversion on Leadership Mantra which truly an inspirational & highly motivating.

Perfectus Announces Industry’s First SystemVerilog-based OVM Tested ONFi Verification IP for ONFi 2.1 Specification

SANTA CLARA, Calif., Jun 22, 2009 (BUSINESS WIRE) -- Santa Clara-based Perfectus Technology, the leading provider of Verification IPs, today announced the availability of ONFi (Open NAND Flash Interface) Verification IP (VIP) product based on the ONFi 2.1 specification. This is the industry's first SystemVerilog-based, OVM-based ONFi VIP with a very sophisticated Verification Engine that will help in accelerating the ONFi-based IP/FPGA/ASIC/SOC/Silicon verification cycle with higher reliability and greater assurance for verification of device. The ONFi VIP is tested to work in the Mentor Graphics(R) Questa(R) Verification Platform.

The ONFi VIP comprises a complete verification environment including test generation, assertion checking and monitoring, and functional coverage. The VIP has a rich set of constrainable parameters, sequence library, powerful error injection capabilities, APIs and Callbacks for user configurability. The VIP is configurable and extensible to satisfy each specific verification environment's requirements. The VIP complies with OVM 2.0.

"Perfectus ONFi Verification IP improves productivity of the verification engineer by using a readily available sequence library to create the verification scenarios," said Sheetal Kammaje, marketing manager of Perfectus.

"Perfectus VIP also helps with the tracking of verification progress with the use of functional coverage." The ONFi VIP verifies Open NAND Flash Interface-based devices. ONFi 2.1 offers simplified flash controller design, but pushes performance levels to a new range--166 megabytes per second (MB/s) to 200 MB/s. Using ONFi strengthens compatibility and interoperability of NAND devices from different vendors.

(http://onfi.org/) The ONFi VIP supports asynchronous and source synchronous modes with all timing modes. It supports up to 4 Target NAND Flash devices with unlimited LOGICAL UNIT, BLOCK & PAGE. For more information visit www.perfectus.com/products-onfi.html The special feature of this product is the reports generated by the Genie-Interface-Inspector. Reports include a Functional Coverage report which helps to identify what functionality has been tested; an Error Inspection report which specifies the errors that were tested and errors that were not tested; a Protocol Inspection report which shows the percentage of ONFi 2.1 specification compliance; and a Features Coverage report which shows the percentage of features covered.

"We are pleased Perfectus has made available the first OVM-tested ONFi verification IP validated to run on the Questa platform," said Dennis Brophy, director of strategic business development, Mentor Graphics Corporation. "As an active member of the Mentor Graphics Questa Vanguard Partnership program, Perfectus works together with Mentor to improve design and verification productivity." Pricing and Availability The ONFi 2.1 VIP is available now. For pricing and additional information, please contact sales@perfectus.com or 408-748-8900, x5632.

About Perfectus Perfectus is a leading provider of very high quality and completely-configurable Verification IPs. Perfectus offers several Verification IP products which include AMBA: AHB, APB & AXI, Ethernet, Fibre Channel, I2C, ONFi, PCIe, SAS, SATA, SMBus, SPI 4.2, OCP, USB3.0 and USB 2.0.

For more information about Perfectus Corp, please email us at sales@Perfectus.com or visit our website at www.Perfectus.com.

Generic Interface Inspector in System Verilog

Today complexity of chip is increased so the complexity of verification process because of time to market factor & quality of deliverable. In Entire Design Cycle from specs to silicon verification is process which takes maximum time in cycle. if we can get rid of some of verification effort then we should beat TTM factor with quality deliverable.

So the Re usability is a need of an hour to achieve this goal.
How we can resolve this issue and what exactly we re-use to achieve our goal ?


In Design cycle there are two different type of functional verification we target.Module level verification & Chip Level Verification. Almost all the peripherals inside SOC we use to verify first at module level and then we test the same peripheral inside the system. We target similar behaviour of the peripherals in both type of verification. But we use to verify same peripherals separately in both the level with same scenario & checks. we build different components to verify the same thing in different environment which takes lot of time to code components and to verify it.

During Verification process of standard protocols we use to verify design against all the Rules at pin level & block levels.Most of the protocols have Host & Device (Master or slave) blocks which communicate through the common bus for data transfer.

if you compare checker rule list of all standard protocols you will find that most of the checks are common at pin level and at block level.we need some mechanism which allow us to to re-use this common set of checks across different standard protocols and different kind of verification environment(Module & SOC).


if somehow we can reduce this gap by using same components in both type of verification & different protocols then it will save most of time of coding and we can beat TTM with Quality deliverable.

This protocol interface inspector provide library of common checks at block level,pin level & timing level which user can access from library & implement their own set of check rules by directly using or enhancing the task or function from libraries.

This Generic Protocol Interface Inspector probe to this common bus to access the data on the interface and validate against all the rules should be followed by standard protocol from Both Host & Device level by using common library developed implement protocol related checks. it will inspect transaction from host & validate it and expect some transaction from Device and validate transaction from device.

This Protocol Interface inspector will also verify the timing related rules on bus using assertion & also provide hook for enhancement to verify more rules by user.

This Protocol Interface Inspector will also verify Pin level activity on the Bus for example during certain mode of operation behaviour of pins changes & this protocol inspector validates pin level activity against all protocols pin related rules.

These Protocol Interface inspectors have Host Level & Device Level Blocks to verify all the Rules of given transaction from Host & Device.

This Protocol Interface inspector will do coverage analysis on the Bus and generate report of functionality coverage of interface. it also give report of all scenario & Errors.

This Protocol Interface will check all the rules, pin level assertions & coverage data to early verification closer.


We can use this Protocol Interface to Verify most of the standard protocols by using common library & also to verify any standards protocols Host Module, Device module at module level & Inside SOC as independent component. We need to connect all interface ports to this protocol inspector and all rules related to protocol will be verified.


so, this Generic Protocol Inspector reusable which can save lot of coding time of verification process.

Pa Pa Pagleeeeee..

Today i am daring to start writing blog bcoz i think i am not a good writer but i thought let me share my thought with rest of the world.so, let start my pa pa paglee(a child who just try to walk) in blog world. while coming back from office lot of thoughts were running into my mind.due to slowdown & current scenario of job market.not a single positive news in last few days & its been verylong since i heard any good news.i don't remember when last i heard any good news but its life & wehave to move on with keeping hope alive.now a days i am reading LK adavani's autobiography(My County My Life) & i came accross nice thought "TOUGH TIMES DON’T LAST; TOUGH MEN DO".we all know this situation will not remain for a long & one day some good news will come. When i reached to my home & my little princess vaishvi (she is just one year old)looked at me and gave 1000 watt smile & threw all toys from her hand and started running (On her knee) towards me.i took her in my hand and forgot all tension, worries & tiredness within one second. After one hour i was playing with her & during that i found that she is now be able to stand on her own feet without any support then she slowly started walking around 3-4 step(In gujarati we use to say PA PA PAGLEE...) & then she fall down on my hand.i was amaze to see that & coudnt explain my feelin. its always amazing to see when your kid is standing on her feet & you want to share your joy with rest of the world(Thats why i started wrting blog..ha ha ha).so,i thought let me share this first with my parents and i called up to bhuj to give this news.my parents were delighted to know that vaishvi has actully started walking & my papa told me its not only good but a great news. At 7 pm i was worried about good news & at 10 pm on same day i was giving great news to my parents.