Few points before heading towards simulation debug -
1. Ask yourself, do you know what is the DUT ?
2. Do you have enough information , what is the driving signals and what signals to monitor?
3. Do you have enough information about the verification environment ?
If your answer is yes for all of 3 questions , then you can go through the steps mentioned below , and if your answer is "NO" for any of the question .. I know you will go through the steps below to know how to debug a simulation. :) not an issue , it's human nature.
I think it's good if you know the verification environment. What testbench is driving to DUT and what
response is expected from DUT.
Go through the below steps :-
1. Try to identify issue , it could be in testbench or DUT , make sure either one is correct and behaving as expected.
2. If issue is in DUT, then try to break your testcase , identify which part of testcase is failing.
3. Once you know functionality A is not working in Dut, then may be fix RTL if you have RTL and confirmed that issue is in RTL.
4. if you are working on IP level , then it is easy to debug. But at SoC level, it becomes very difficult to identify issue and debugging due to simulation time and simulation dump size.
5. If simulation time is very big, then optimized initial startup sequence , some of functionality may not required and can be skipped during debugging.
6. Dump signals which are required , do not dump all signals in design.
7. For modelsim/Questa, you can make .do file , which can have particular signals required in debugging.
8. Always dump common buses where you can see the traffic going in/out inside DUT, this will help to understand the failure case and time.
I think knowing the environment is the key point. Even if you dont know much about the DUT , you can still confirm with designer that there is bug in DUT.
To know more about the Verification environment , go through the below link.
Verification Environment
As usual , comments are most welcome and if any one want to add something, please put on comment. I will try my best to keep this thread alive.
Thanks a lot.
1. Ask yourself, do you know what is the DUT ?
2. Do you have enough information , what is the driving signals and what signals to monitor?
3. Do you have enough information about the verification environment ?
If your answer is yes for all of 3 questions , then you can go through the steps mentioned below , and if your answer is "NO" for any of the question .. I know you will go through the steps below to know how to debug a simulation. :) not an issue , it's human nature.
I think it's good if you know the verification environment. What testbench is driving to DUT and what
response is expected from DUT.
Go through the below steps :-
1. Try to identify issue , it could be in testbench or DUT , make sure either one is correct and behaving as expected.
2. If issue is in DUT, then try to break your testcase , identify which part of testcase is failing.
3. Once you know functionality A is not working in Dut, then may be fix RTL if you have RTL and confirmed that issue is in RTL.
4. if you are working on IP level , then it is easy to debug. But at SoC level, it becomes very difficult to identify issue and debugging due to simulation time and simulation dump size.
5. If simulation time is very big, then optimized initial startup sequence , some of functionality may not required and can be skipped during debugging.
6. Dump signals which are required , do not dump all signals in design.
7. For modelsim/Questa, you can make .do file , which can have particular signals required in debugging.
8. Always dump common buses where you can see the traffic going in/out inside DUT, this will help to understand the failure case and time.
I think knowing the environment is the key point. Even if you dont know much about the DUT , you can still confirm with designer that there is bug in DUT.
To know more about the Verification environment , go through the below link.
Verification Environment
As usual , comments are most welcome and if any one want to add something, please put on comment. I will try my best to keep this thread alive.
Thanks a lot.
No comments:
Post a Comment