NVIDIA Interview question? ASIC Verification

asic verification interview questions

Hi every one,

Yesterday i got an interview with NVIDIA.
They asked one intresting interview question.
What if design engineer and verification engineer do the same mistake in Test bench BFM and RTL(DUT)? How can you able to detect errors?

My answer: Some bugs we can able to detect in FPGA. But he is not convinced

But interviewer big custom chips like Microprocessor , we can't check in FPGA.
What do you do in that case?

Please answer this.

Thanks & Best Regards,
Ram

nvidia interview questions

Code reviews & protocol checkers spring to mind.

verification interview questions

But protocol checker will be developed by Verification engineer.
If that is wrong, errors will occur.

functional verification interview questions

The questions asks if there is a mistake specifically in the BFM though.

nvidia interview

Yes , The mistake is in BFM and Design too.

soc verification interview questions

only when you verify design with other 'stable' BFM, you can catch that bug ... usualy an IP gets verified in multiple environments .. like block level test bench, out of box testbench (connecting DUT back to back), full fledged testbench using proven BFM, SoC level testbench using processor and all that etc... this all environments SHOULD be executed by diferent persons and so you should be able to catch that bug in one of this testbench ...

if still you are not finding that bug, customer is defenetely going to catch it ..


JD

nvidia asic

golden reference model should be there

nvidia interview process

I can go for functional coverage and code reviews.
This will solve some bugs in Testbench.

nvidia asic interview

Multiple ways do exist to catch these types of errors...few of them are
1. Spyglass - Rule checker
2. Use Assertions
3. Functional coverage
4. Code Review

verification interview question

Answer
In addition to rtl engineer and verification engineer, we need model engineer to write c model for the same design. The verification engineer generates test cases to compare the rtl and c simulation outputs. By this way, we can reduce the same mistake to the lowest level.

interview for verification engineer

I think function coverage is good for verificaiton! and the BFM should be good!

nvidia interview question

This is an ever green problem - how "golden" is your "golden ref model"? As the complexity grows, you add more orthogonal languages/techniques and hope that atleast one of them shall catch the intent correctly (and flag the issues, if any). On a slightly different note companies like Certess/SpringSoft are introducing the concept of "Functional Qualification", see some of my colleague's comments on this technology at:

https://sv-verif.blogspot.com/2009/03/ccd-my-read-of-certess-technology-and.html

Ajeetha, CVC
www.cvcblr.com

design verification interview questions

I think the interview meant to say the reference model instead of the BFM, which is suppose to predict the expected result out of the DUT.

Two ways we can detect this problem. One is with code review and the other is to check the intent in the test itself and not completely rely on the reference model. For example, if the DUT is suppose to drop all packets with lengths shorter than 64 bytes, but some how both the DUT and reference model only drop packets that are shorter than 60 bytes, than packets with lengths from 61-64 bytes will not be dropped, both in the DUT and the reference model, and your test will say PASS. But if in your test, you check to make sure the DUT's drop counter's value is equal to the number of expected packet drop due to short length (<64B), than if it is not what you expected, than you know the DUT has a bug.


Now, do this in every test can be cumbersome and this kind of double checking the reference model defeats the purpose of having a reference model in the first placet. However, if it's not too difficult, it is recommended you do this. I have 10 years of ASIC/FPGA verification experience and I have seen verification engineer just look at the RTL and basically copy the code and use it in their reference model, and therefore, will have the same bug and they won't be able to detect it until it's too late.

- Hung

Currently Verification is subjective( depends on the verifier).

Functional qualification will make the subjective verification to objective and there by addressing similar bugs.

The philosophy of Functional qualification is the RTL is modified and check if the existing TB is able to detect this.

In this case if the DUT and BFM are similar(faulty) there might me some areas which might point to this wrong similarity.

Using a Cyclic Redundancy Check?