Defining test-case complexity [Q] 
Author Message
 Defining test-case complexity [Q]

I'm involved with a group of people who are trying to set up
some benchmarks for test-vector qualification using Cadence's
Verilog-XL simulator.  One of the interim goals of this effort
is to arrive at some means of defining quantities that will
represent the level of complexity for test case designs and
vector sets.  Aspects of the designs such as the ratio of
sequential to combinational cell models or level of hierarchy
are under consideration.  Also being examined are total num-
ber of toggles vs. number of vectors for vector sets.

If anybody has any ideas on how to define metrics such as this,
or can point me to some literature that would be helpful, I'd
appreciate it.  Thanks in advance.

---
Mark Shaw
Texas Instruments - ASIC
214.917.7124



Sun, 06 Oct 1996 00:47:02 GMT  
 Defining test-case complexity [Q]
That's a tough one.

Strictly speaking, complexity is a measure of how many different ways you can
communicate with an object. This includes properties and permutations at all protocol
layers.

I'm going to take a SWAG and assert that you probably have some kind of fault model,
probably in the form of a stuck-at fault simulator. In this case, at each level of
protocol, you want to determine the the number of values of properties and the number
of permutations that satisfy completeness of your fault model. This is will be smaller
than the number of test vectors ( most likely ).

Another interesting way to express complexity is that it represents the information
encoded in the vectors after this information has been compressed by the best
possible algorithm.

A correlary to this is that SCAN and ATPG attempt to compress the vectors to the
smallest possible size. SCAN does not make the vectors less complex, it only
alleviates the need to repeat vectors ( which are compressable ) in order to get
the object in a certain desired test state.

The complexity of your effort is the complexity of the vectors plus the complexity
of the theoretical compression algorithm. This is why I write so many transactors.

                                                John Williams



Wed, 09 Oct 1996 01:23:11 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Q: Testing complexity with Python

2. Fully defined case statement?

3. defmacro/define-macro using syntax-case

4. Upper case / Lower case I'm a lost case

5. CASE vs case vs Case...

6. Writing non-intrusive test cases?

7. Test Case Patterns

8. test case generator

9. Define a General Test Class

10. Writing test cases in Eiffel; XP for Eiffel

11. Crashproofing - test cases

12. A test case for the compound variable question...

 

 
Powered by phpBB® Forum Software