Al Hoang

August 12, 2006

How to make a DSP hardware project be on time

Filed under: tagme — @ 10:48 pm

Here is an article describing

a fairy tale (sadly) idea of how one would run a project for creating a product

from DSP chips. I’ll have to say it makes a lot of sense but what would

be more interesting is some hard data on anyone that has actually managed to

apply this idea:

This is OK for a simple algorithm, but what if it is even moderately complex?

Then you are dealing with (i) a very complex algorithm and (ii) very complex

assembler all at the same time. This is usually too much for mere mortals (and

even minor deities). The result is long, painful development, failed projects,

late nights, angry spouses, and lots of pizza (well its not all bad I guess).

The trick is to divide and conquer. Make sure we are only hitting one tough

problem at any given time.

One approach I have found very useful is bit

exact porting to assembler.

There are two important steps:

  1. At the fixed point C stage, you test very very carefully. Run batteries

    of tests and simulations. These can be performed on a regular PC in non real

    time, using powerful debuggers. The idea is to verify that:

    (i) The algorithm is OK and

    (ii) The fixed point port works OK.

    In particular (ii) is very tough, so its nice to handle this in a relatively

    benign environment like a PC or

    workstation.

  2. Port each function to real time assembler one by one. Test each function

    against the fixed point C reference. Make sure the functions give IDENTICAL

    output – right down to the last bit. This takes a lot of discipline – near

    enough is NOT good enough.

Read it yourself

Kudos to Joel’s Reddit page for this one.

The state of software engineering

Filed under: tagme — @ 10:41 pm

If you’re curious on one person’s viewpoint on software engineering as a

discipline (academic and professional) this is a very nice summary / rant

on it. One minor niggling point is that I think the author could spend

a little time fixing small grammatical mistakes. Since the mistakes

make a serious criticism like this look a little childish. But only on the

surface. Here’s a choice

snippet:

First, let’s touch on requirements gathering. No where in the book did Pressman

illustrate how most engineers actually get their requirements. He presented

some idealized scenarios, and correctly illustrated the benefits of use cases.

But in the real world, most requirements come from emails and rough wireframes.

Assuming that we can start by writing the specification is folly. What we

should be studying is how to turn a screen shot created in Photoshop in to a

real specification. Engineers need to learn how to annotate a screen shot with

input validation rules. They also need to error messages and edge cases. And

they need to do it with the understanding that their stakeholders don’t know or

care about such matters unless you bring it up to them first.

Read it yourself

Kudos to Joel’s Reddit page for this one

Bruce Eckel takes another look at Ruby

Filed under: ruby — hoanga @ 10:36 pm

Bruce Eckel of

Thinking in Java fame takes

a second

look at Ruby. This time he has far less harsh words than his

previous look at it (Note that the original post that Eckel made on

Ruby seems to be MIA on his website. I’m a little miffed at that…)

His second time around he seems a little more impressed but I have to agree

with some readers who pointed out that if he bothered to read the

Pickaxe book he would have found a good portion of these features in Ruby.

Although for a counterpoint, I’ve tried reading some comparisons of Python

and Ruby and most of them end up in a ‘mine is bigger’ argument rather than

try to really see what is different. Mr. Eckel has spent some time

summarizing the differences. The reason it’s easier to believe him is

because he is staunch follower of Python.

Read his

second look yourself

Powered by WordPress

Protected by AkismetBlog with WordPress