Embedded x86 design verification software.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello all,

I am about to work on my first embedded x86 project. I have four years of
embedded software experience. However, all of that experience has been with
ARM, SH, or XScale based hardware. We are doing a custom x86 hardware
platform, and my group is responsible for developing design verification
test software as well final functional test software. To be perfectly clear,
I'll share my definitions of those two terms.

- Design verification tests are code that we run to verify that the hardware
is put together correctly. This might be some code that simply does reads
and writes to a specific memory area such that we can capture the bus
transactions on a scope and verify timing values, or it might involve
sending and receiving data on a serial port or network connection. This code
gets run after every board spin to see if we need to do another one :)

- Final functional test software is a suite of tests that are run at the end
of the manufacturing line. They are typically designed to run very fast and
verify that the device has been put together properly. For instance, code
that sends and receives data over the serial port. I know I used that as an
example above however, in this case, the goal would be to verify that the
manufacturer actually soldered the connector on correctly. The focus of the
code above would be to subject the hardware to much greater scrutiny.

Anyway I don't want to get into a semantic argument as I imagine that of the
engineers within this group have a pretty good grasp of what I'm talking

I am looking for advice on how to go about performing these tests. I don't
have many resources available to me, so I want to make as much use of
commercial off the shelf (COTS) software as possible. We are having a BIOS
vendor come out and get the BIOS up and running on the hardware. I expect
that simply bringing up the BIOS will shake out a number of hardware bugs
however, I am certain that more test code will have to be written. So, what
is the best way to go about re-using other people's work out there. If I get
DOS running, are there test suites that I can use? Are there test suites
that can run directly on top of the BIOS?

Any advice would be greatly appreciated.

Best regards,

It wasn't easy being Greazy ....but it was interesting.

Re: Embedded x86 design verification software.

Quoted text here. Click to load it

[-----%X-----------Query about hardware testing----------%X------]
Quoted text here. Click to load it

About 18 months to 2 years ago in this ng  there was a very interesting
thread on hardware verification methods and techniques that could be used
to confirm everything about the hardware you have to look at. There was
even a specific order of running the tests to ensure that no hidden faults
existed. I am away from the PC that I was using at that time and where I
saved the best links (til Sept 1st anyway). I think the title included the
phrase "hardware testing".

The best way to write such tests is in the processor machine code so that
you have tight control over the exact code that gets implemented. Once you
have written the tests you need ensure that they get into your library of
useful code so that you have them for the future.

Some links, I just googled out for you, from the past that may also help
(you may need to stitch these lines back together again):-

http://groups.google.com/groups?q=hardware+testing+group:comp.arch.embedded .*&hl=en&lr=&ie=UTF-8&group=comp.arch.embedded.*&selm38%24E1AC.26C2C16%40wordnet.att.net&rnum=2

http://groups.google.com/groups?q=hardware+testing+group:comp.arch.embedded .*&start20%&hl=en&lr=&ie=UTF-8&group=comp.arch.embedded.*&selm=acks8p%242ii%2406%241%40news.t-online.com&rnum27%

http://groups.google.com/groups?q=POST+group:comp.arch.embedded .*&hl=en&lr=&ie=UTF-8&group=comp.arch.embedded.*&selmD6%4DI1.Gov%40dcache.uucp&rnum=5

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm36%1e1687.0%40139.134.5.33&rnum=2&prev=/groups%3Fq%3DProcessor%2BTesting%2Bgroup:comp.arch.embedded .*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.arch.embedded.*%26selm%3D361e1687.0%2540139.134.5.33%26rnum%3D2

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm39%EF5ED1.3E76F87A%40fltvis.com&rnum=8&prev=/groups%3Fq%3DProcessor%2BTesting%2Bgroup:comp.arch.embedded .*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.arch.embedded.*%26selm%3D39EF5ED1.3E76F87A%2540fltvis.com%26rnum%3D8

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm37%3B5122.63997D47%40nospam.ix.netcom.com&rnum10%&prev=/groups%3Fq%3DProcessor%2BTesting%2Bgroup:comp.arch.embedded .*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.arch.embedded.*%26selm%3D373B5122.63997D47%2540nospam.ix.netcom.com%26rnum%3D10

Hope those give you some idea. Sorry that the links are so long a line but
that is the way they come.

The code can be put together into a ROM (or whatever) and a guide to the
test engineers given so that they know during moments when particular
patterns of lights, messages appear they should be checking specific test
points (I am presuming that this is for a production line situation but is
helpful in small batch production scenarios as well).

We've slightly trimmed the long signature. Click to see the full one.

Site Timeline