[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers
Mark McDougall wrote:
Michael J. Mahon wrote:
Speedy development cycles--twice a minute instead of twice a day--can
have a corrosive effect on a programmer's discipline, and his grasp
of the program. Having to wait allows time to think, and re-think,
until a clearer understanding emerges.
True, though FPGA development has gone some way to curing that for me at
least! When you've got 1-2 hour build times, you tend to spend a lot
more time doing simulation and staring for days at those wiggly little
coloured lines! In fact, there's generally a *lot* more code (and time
and effort) in the testbench than the actual design under test. I wonder
how many software engineers can claim the same?
Interesting question.
I spent a lot of time trying to convince a bunch of software engineers
that their problem--more than half of their time to release a product
revision spent in system reliablilty testing--could be largely solved
by creating a "test scaffold" to simulate the running environment of
each major module, and feed it errors, race conditions, and load under
the direction of test scripts.
The scripts would test all module functionality, corner conditions, and
error responses (using both "black box" and "white box" approaches) and
would be extended (white box) to test each code change made with each
revision.
Using this approach, a project is responsible not only for delivering
the module to go into the product, but also for building and extending
the test scaffold and scripts that do regression and reliablity testing.
I could demonstrate how such an approach would provide much faster
regression testing and *much* more stress testing than weeks of "real"
running in a minute or so (by spending all its time doing real testing
as opposed to repeating the same "usual" functions endlessly)!
A module regression test would be an automatic part of every module
"make", and reliability testing could be done at least daily.
In short, I failed. I could not convince a single project manager to
take this approach, even though it provided the single best opportunity
to reduce time-to-market. Too different, might not work, and--the big
one--"what will happen to me if it doesn't work?"
It's much "safer" to keep doing the same old thing that works very
poorly than to take a risk on a new method that could revolutionize
the development process.
-michael
Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."