Subj : Re: Not debugging?
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : Greg Menke
Date : Sat Aug 27 2005 06:22 pm

"Phlip" <phlipcpp@yahoo.com> writes:

> Greg Menke wrote:
> 
> >> You describe a legacy situation - someone else invented this bizarro
> >> hardware, and legacy situations require debugging to learn their
> >> characteristics.
> >
> > No I don't.  I describe a realtime system- or even a simple device
> > driver.  There are lots of those, new and old.
> 
> The define "legacy" as "requires debugging".

Bizarre.


> > Say you wrote some subsystem on this embedded system, and you
> > implemented some kind of test framework to help you get it as
> > functionally debugged as possible.  What you've tested is your inputs,
> > outputs and algorithms work in an fairly abstract and simplistic
> > situation.  Thats helpful for first order easy debugging, but you're
> > going to be doing it the hard way along with everybody else once the
> > software is on the hardware and some of the unknown idiosyncracies of
> > the system start showing up.  More of the unknown idiosyncracies will
> > appear over time.  And at this stage, your emulator is pretty much
> > useless because nobody cares about what it says when the real thing is
> > sitting in the lab & thats were the bugs are.
> 
> This sounds like the code went through an emulation phase and then a real 
> thing phase.

Nope- went through breadboard designs of the hardware using inputs &
outputs first from emulation hardware and eventually from the real
hardware.  The breadboard designs are used to work up hardware and
software designs and implementations, feeding back changes & bugfixes,
etc into the evolving specs.  Ideally, the working software meets the
working hardware later on in the project.  Low fidelity emulation is
pretty handy for easier classes of bugs early on; mismatched or unpacked
structs, endian stuff, etc..  But race conditions and pathological i/o
states (the harder problems) often depend on the real hardware in the
real operating environment (maybe interrupt timing changes because
capacitors & clocks drift when the system goes below freezing, for
example).


> Ideally, I would configure one button on my editor to run all tests against 
> the emulator, then run all possible tests against the hardware. If the code 
> fails in the hardware I would trivially attempt to upgrade the emulator to 
> match the fault, so the code also fails with the emulator. But this is 
> speculation, and of course it won't prevent the need to debug against the 
> hardware.

Neat.  Who's going to pay for the emulator (build it & prove that it
matches the hardware- and keep it matching) when we also have to do the
real system?  

Now one place that emulators are really handy are for working up smaller
subsystem elements; ie logic in a single fpga or related fpga's- then
excercising the i/o is a bit easier.


> 
> Realistically, you are apparently relentlessly testing, and admittedly in a 
> "legacy" situation that prevents you from using tests to make the hardware 
> more bug resistant. Carry on!
> 

We don't get many opportunites to make hardware more bug resistant.  If
software discovers a discrepancy in the documented interface we can
sometimes get fixes back into hardware, but it has to be well proven.
Early in the hardware lifecycle its easier to get changes to the
interface specs, but later on the software people pretty much have to
lump it.

Gregm

.