| Login | | Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name. | |
| Who's Online | There are currently, 55 guest(s) and 0 member(s) that are online.
You are Anonymous user. You can register for free by clicking here | |
 | |
|
Verification Guild: Forums |
|
| View previous topic :: View next topic |
| Author |
Message |
z
Senior
![]()
Joined: Jan 09, 2004
Posts: 92
|
 Posted: Sat Mar 06, 2004 3:32 pm Post subject: Re: Debugging long random simulations |
 |
|
| confused wrote: |
The easy idea is to run short tests. Is it a good idea to always avoid long tests? Do people run single clock cycle tests? How short is not too short? The key in short tests (similar to the earlier idea) is the internal structure of the design. Shorter tests normally require more direct accesses to the internal signals in the design, and these internal signals can be changed in the fixes. Is it generally a good idea for the testbench to depend heavily on the internal details of the design? Not if you want to avoid changing the testbench whenever the design is fixed. An apparent benefit of long tests is to test operations from various states of the design. Engineers usually do not accurately know what all possible states are. If they know, it is still a good idea to be sure. It is bad if an impossible state is actually possible and it causes problems. Is it a good idea to count all states as possible and randomly start operations from all of them in short tests? |
Based on Alexander's transaction view, a short test should not be shorter than a single transaction. Such tests usually do not heavily depend on internal details of the design. Tests involving 2 or 3 transactions are sometimes even better because the boundaries between transactions are often interesting.
Longer tests may possibly exercise more states than shorter tests do. It is the best if short tests can also exercise more states. |
|
| Back to top |
|
 |
z
Senior
![]()
Joined: Jan 09, 2004
Posts: 92
|
| Posted: Sat Apr 24, 2004 6:07 am Post subject: verification methodology to shorten debugging cycle |
|
|
To a degree, debugging speed determines a project's cost. The cost of architecting, designing and coding the RTL, the verification environment, and the tests would not change too surprisingly. The number of bugs in these can also be estimated reasonably based on past experiences. Then, the time to find and isolate each bug can be surprising different. Some times it is hours, and other times it can be days.
Therefore, a major consideration in verification methodology is to reduce the average debugging cycle for each bug. If it takes A hours to run a test and it takes B hours to analyze the data collected from the simulation, B is likely a large number if A is large. So, simplifying each test (to reduce both the run times and the amounts of data that have to be analyzed in debugging) is critical.
Verifiying smaller blocks of the design is often discussed. It simplifies tests, but it often significantly increases the work on verification environments.
What are the issues with using shorter tests for the whole design? Most tests have to skip the initialization sequence. Some registers need to be set without using the normal read/write procedures. What else? |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
| |
|
|
Forum FAQ
Search
Usergroups
Profile
Digest
Log in
