Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #20059

Re: processor core validation

Cross-posted to 2 groups.

Followups directed to: comp.arch.embedded

Show key headers only | View raw

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
> You could have a combination hardware/software test harness, where you 
> have a full test app (or perhaps an app that loops through the processor 
> states that are of most interest) while at the same time the processor is 
> getting interrupted by an asynchronous source that either has a different 
> period from the processor's, or which is intentionally random.

This test harness could effectively be running on a simulator, where I 
could use a golden model and crosscheck that throwing random interrupts 
does not cause any deviation from the golden model behavior.

The main difficulty I see would be the functional coverage model I need 
to put in place to tell me I'm done.

There might be corner cases where the only solution would be crafting a 
special purpose test program to generate stimuli (or sequences of 
stimuli) which might be very difficult to achieve otherwise (some sort 
of direct testing and random testing).

> Just going through the thing step-by-step and, positing problem modes, and 
> examining the code to ask "how am I going to test for this?" will force 
> you to think in depth about everything -- one of the frequent ways that 
> TDD helps me to find bugs is by forcing me to discover them in the test 
> design, before I even get to the point of throwing software at the test.

I can simply get the spec of the processor and start to classify the 
requirements and then go one by one trying to build my functional 
coverage model. It is possible that going through the code would not be 
needed, even though it might help us discovering corner cases.

Assuming the golden model is provided (I've found one on OVP, yet not 
sure whether it is the right one!) I'll just verify compliance to the 
golden model and maybe present some usecases where some high level 
software is able to run and work without crashing.

The black box approach has some advantages:

1. no need to know the details (unless we need a fix) 
2. bfm for processor's interface are /available/ (write_mem, read_mem) 
3. heuristic approach (let's see if it breaks!)

OTOH we might face the need to open the box and go deeper with our 
verification, where interactions between internal elements have to be 
analyzed.

With the hypothesis that the processor 'state' does not depend on 
previous instructions (there's no cache), the order of the instructions 
does not necessarily matter. Should this be the case I'll probably can 
simply live with throwing random instructions at it.

Al

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

processor core validation al.basili@gmail.com (alb) - 2015-02-08 22:02 +0000
  Re: processor core validation Tim Wescott <tim@seemywebsite.com> - 2015-02-08 18:13 -0600
    Re: processor core validation al.basili@gmail.com (alb) - 2015-02-09 17:03 +0000
      Re: processor core validation Tim Wescott <seemywebsite@myfooter.really> - 2015-02-09 13:37 -0600
        Re: processor core validation al.basili@gmail.com (alb) - 2015-02-11 22:12 +0000
          Re: processor core validation rickman <gnuarm@gmail.com> - 2015-02-11 20:18 -0500
            Re: processor core validation al.basili@gmail.com (alb) - 2015-02-12 08:08 +0000
  Re: processor core validation HT-Lab <hans64@htminuslab.com> - 2015-02-09 09:04 +0000
    Re: processor core validation Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-02-09 09:41 +0000
      Re: processor core validation HT-Lab <hans64@htminuslab.com> - 2015-02-09 11:35 +0000
      Re: processor core validation Tom Gardner <spamjunk@blueyonder.co.uk> - 2015-02-09 12:19 +0000
    Re: processor core validation al.basili@gmail.com (alb) - 2015-02-09 17:16 +0000

csiph-web