The philosophy of BB

The philosophy of BB

1. A BB is either simple or complex. It should never be complicated. 
1. The difference between complex and complicated is that complex can always be broken down in a sum of simple things. 
2. And complicated is well .. complicated. For instance a lot of software is complicated.
2. People familiar with the evolution of  electronics, remember the SSI, MSI, LSI stages and can put the heydey of BBs as the days of Bit Slice. 
1. A bit slice was built with simple elements and a bit slice was itself the building block used in upper dsp Building Blocks, dsp functional Blocks (FFTer, Filter, Correlator), dsp CPU  or even the DEC mini-computer. 
3. For instance a standard dsp CPU (called DSP thanks to TI) are made of 4 standard bit slice blocks (ALU, MULT, AGU,  LSU) + memories + I/O Space.
4. A very good DSP design should have a maximum of 3 hierarchical levels (MSI, LSI, Final product). 
1. Anything above 5 levels is prohibitive and should not be tackled here.
5. Because we rely on a hierarchy of blocks, testing of each block is vital to the whole process. 
1. A bug in a low level block is a disaster since it will be repeated hundred of times over several final products. 
6. Same thing for an inefficient block but with a twist.
1. Contrary to a bug, efficiency is a relative term. 
1. You can redesign the BB with a different name. 
2. (for sophisticated designer) you can redesign an upward compatible block  with the same name 
• but then you need a very hefty test suite.
7. So what about repairing a bug? 
1. In my book, a bug is both visible and NOT compatible with itself. 
2. Hence if you repair a bug you don't know the result; somewhere down the line somebody wrote software taking this bug into account or somebody used the BB taking the bug into account.
8. This is the INTRINSIC problem to the BB approach. You are going BOTTOM UP in the definition. So forget about reparing bugs. Instead create another BB.