processor core validation

[alb]

Hi everyone,

I was wondering if anyone can point me to some formal method to validate
a soft processor core.

We have the source code (vhdl) and a simulation environment to load
programs and execute them, but I'm not sure in this case code coeverage
will be sufficient. What about cases like interrupt handling?

I can run Dhrystone or CoreMark, but will it be sufficient?

Any idea/pointer/comment is appreciated,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[HT-Lab]

On 08/02/2015 22:02, alb wrote:

Hi everyone,

Hi Al,

I was wondering if anyone can point me to some formal method to validate
a soft processor core.

We have the source code (vhdl) and a simulation environment to load
programs and execute them, but I'm not sure in this case code coeverage
will be sufficient. What about cases like interrupt handling?

I assume you know that Code Coverage has nothing to do with formal
Verification and/or tells you if your processor is bug free, it just
measure of the quality of your testbench.

If you want to formally test your processor then AFAIK your only option
is to start writing lots of assertion and spend a years salary on a
formal tool (solidify/Questa formal/etc). You can also run assertions in
your simulator (like Modelsim DE/Riviera Pro) but this will not be
exhaustive.

If your processor is small you might get away of writing top level
assertions but most likely (due to the cone of logic) you will have to
formally prove sub-blocks and use good old testvectors for the
interconnects.

I can run Dhrystone or CoreMark, but will it be sufficient?

What do you think ;-)

If you have a golden reference model then I would suggest a regression
suite with lots of constrained random generated instructions, interrupt
test programs, OS load, etc and comparing the output to your reference
model.

I would also suggest you look up the (old) Viper processor which was a
hot topic when I was working in the space industry.

Good luck,

Regards,
Hans.
www.ht-lab.com

Any idea/pointer/comment is appreciated,

Al

 

[alb]

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

 

Hi everyone,

I was wondering if anyone can point me to some formal method to validate
a soft processor core.

We have the source code (vhdl) and a simulation environment to load
programs and execute them, but I'm not sure in this case code coeverage
will be sufficient. What about cases like interrupt handling?

I can run Dhrystone or CoreMark, but will it be sufficient?

Any idea/pointer/comment is appreciated,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

------------------
You may find this page useful:
"In this document I show how to generate code for ARM processor and use i
in VHDL or VERILOG simulation.
The flow is from C code or assembly into VERILOG READMEMHEX format.
First you need to write a program in C or assembly. ..."
http://bknpk.ddns.net/my_web/AHB_MON/ARM_assembly/top.html
--------------------------------------
Posted through http://www.FPGARelated.com