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.

Matching functions to structures

====== Building Block ISSUES  ======= 

Matching functions to structures

When designing a new BB it is because you need it. Hence, we call this need: a strictly functional need. There are two ways to go:
- stick to it and solve the present issue.
- have a broader view and design a more general purpose brick which can be reused.
A third case happens when the functional block can be turned into a generic structural block for no additional price. So before designing a new block, it is worth asking oneself.
Can I make this BB more generic?
Let us take as example the addition needed in a complex multiplication:
zr = xr*kr -xi*ki
zi = xi*kr + xi*kr
same as
zr = p1 - p2
zi=  p3 + p4
If we use a dual multiplier, the 4 multiplications can be done in 2 cycles.

Then it must be followed by two BBs for the complete equations. We now write the equations as follows.

1.   [zr zi] = thru22(p1,p3)   %   zr=p1 zi=p3
2.   [zi  zr]= addsub42(zi,p4,zr,p2) %zi= zi+p4  zr=zr+p2

It is easy to see that the two BBs are generic but the inputs and the equations are not straightforward..

The standard alternative is

1. zr = sub(p1,p2)
2. zi=  add(p3,p4)

which is simpler. So what are taking about here?

In fact there are two issues with the standard way;

1. It needs the 4 input data on the first dual multiplication
2. It does not work when we want  real_imag  to be in the same register so that the complex number is considered an entity made of 2 parts..

T.O.C 4Nov2015

1. So you want to be a DSP architect?
1. THE LONG STORY
1. DSP Architecture today
2. BACKGROUND CHECKS 
• Henneson and Patersy
• Coprocessing
• Benchmarking
• BDT as an architectural tool
• 
  
3. BUILDING BLOCK ISSUES
1. Physical limits
2. Design time, Build time and Run time
4. METHODOLOGY AND TOOL ISSUES
5. FOUND IN THE WEBS
1. The Matlab Engine 
2. Is Kurt Keutzer the Donald Trump of Hardwired Processing? 
3. Found in the cobwebs: my garage
4. The Trailing Edge
6. DSP (GP) ARCHITECTURES 
1. DSP of the First Kind (1980-95)
2. DSP of the Second Kind (1995-2005)
3. DSP of the Third Kind (2010- ?)
4. DSP of the lost kind (1995-2005)
5. DSP  of any kind (1950-2050)
7. FROM DSP TO DSP
1. This wonderful world of DSP
1. A world? More like a sect! 
2. The Pope (Will), the Cardinal (Jeff) and the Wizzard (Gene)  
2. The DSP Old Timer's Club.
3. Stop me if you've heard this one before!
4. DSP history
1. Bit slice: a saga 1975-1985
2. Building Block:  was 1992 and IDT  the last DSP BB? or Weitek?
8. EXAMPLES of Target AS-DSP
1. Analog programs (Basic, HPC and other gizmos)
2. TI C25 Tips and Tricks 
3. SPmag Tips and Tricks
4. 
   
2. BB Level 1
1. Arithmetic BB
2. Bit wise BB
3. Vector BB
3. BB1 DSP STRUCTURES
1. Processing trilogy (ALU, BMU, MULT)  
2. MAC
3. DAU
4. AGU 
5. PCU
6. RF (Register File) and MEM
7. VPU (Vector Processing Units)
8. SU (The Shuffle Unit) 
9. Bit slice: Bit slice building blocks
4. BB2 DSP FUNCTIONS
1. Filter
2. FFT
3. Correlators & bit comm. engines
4. Sampling
5. Matlab functions
5. BB3 MATLAB BB
6. BB4 MATH 
1. including Complex numbers
7. APPENDIX 

Is Kurt Keutzer the Donald Trump of Hardwired Processing?

The answer is No!

The link
http://www.eecs.berkeley.edu/~keutzer/

Background
In the sputtering days of  CPU Architecture, just after the millenium, I remember KK (and Berkeley in general) as a different voice as to which directions to take for future CPUs. Effectivelly here are a few arguments of the time (*):
-  we are now in a hardware cycle as opposed to a software cycle
-  the next step in MIPs is NOT reached by increasing the clock
-  instead programmable logic or FPGA or hardware or ASIP (Application Specific IP)
-  hurray for configurable core (typ. tensilica,  then stretch)
-  hurray hooray for reconfigurable computing (all dead).

Jump to 2015. As I am going through my notes on possible architecture trends (of interest to this Blog), I have 2 KK papers that I want in electronics format. Google the paper name + author and got nothing. Lost in the ozone. Okay I will scan them.
To cut a long story short, the KK I found is not the one I had in mind(*), but still an exciting guy to follow..
Anyway, here is  his web page; among other things, KK mentions that he lost money with Catalytic, sorry, I contributed to that Kurt!
Here is his current interest :
 Exploring Design Patterns for Parallel Computing
which is somehow related to this Blog.
I downloaded 2 papers:
- how to map recursivity in hardware
- speculation.
And the other papers are good too!

(*) as I remember; I might be confused, not sure if KK was leading all that;

1.1 The Long Story

1.1 - THE LONG STORY

The goal of this section is to give some meat (and the background) to our base statements.But it does not try to discuss or justify any of our choices.

• As mentionned in the introduction, we are in the very comfortable position of presenting a system which is outside reality. 
• In effect, all decisions have NO tangible reasons (such as based on cost, design time or available tools and platforms).
• It is all in the eyes of the beholder.

Q&A

• DSP architect is Dead?
• Today DSP architect job's split: 95% platform, 2% Core, 3% tools.
• PLATFORM: 
• Is there a DSP architect in the house? No, he is split into pieces
• The system guy (m-code and simulation) --> 90% of the work
• The DSP guy (*) --> 10% of the work
• The firmware guy: can take the job of the DSP guy, especially writing in C
• The ASIC/FPGA designer:  can take the job of the DSP guy.
• From above, the REAL DSP architect is the system guy? yes
• But this guy is not (does not want to be) an architect
• {..} Here would come all the efforts such as Matlab to C/verilog, System C, etc,, and in general all the failures of the Tool vendors to provide a flow:system to implementation.  

• Why customisation?
• Because we used to be vertical, went horizontal and now we are back to vertical.
• What is accelerated processing? 
• see  IEEE micro july/aug 2008
• Why Matlab? 
• Because it is the most popular system tool.
• Also Matlab is much more than a language (randy's 3 things 1):
• a language, *** 
• an EDE  ****
• a simulation environment *****
• Matlab is not a concurent language (contrary to verilog). Does that prevent you from sleeping? here i avoid the use of the word parallelism because of the funny parfor. 
• What is mapping?
• An analogy: mapping is hardmacro, compiling is soft macro
• An approximation: mapping is by hand, compiling use a tool.
• An aromatism: mapping is an assembler macro, compiling is C
• Can mapping be used with a compiler? 
• You bet! As a matter of fact, it is the only way to be succesful.

T.O.C November 2015

1. So you want to be a DSP architect?
1. THE LONG STORY
1. DSP Architecture today
2. BACKGROUND CHECKS 
• Henneson and Patersy
• Coprocessing
• Benchmarking
• BDT as an architectural tool
• 
  
3. BUILDING BLOCK ISSUES
1. Physical limits
2. Design time, Build time and Run time
4. METHODOLOGY AND TOOL ISSUES
5. FOUND IN THE WEBS
1. The Matlab Engine 
2. Found in the cobwebs: my garage
3. The Trailing Edge
6. DSP (GP) ARCHITECTURES 
1. DSP of the First Kind (1980-95)
2. DSP of the Second Kind (1995-2005)
3. DSP of the Third Kind (2010- ?)
4. DSP of the lost kind (1995-2005)
5. DSP  of any kind (1950-2050)
7. FROM DSP TO DSP
1. This wonderful world of DSP
1. A world? More like a sect! 
2. The Pope (Will), the Cardinal (Jeff) and the Wizzard (Gene)  
2. The DSP Old Timer's Club.
3. Stop me if you've heard this one before!
4. DSP history
1. Bit slice: a saga 1975-1985
2. Building Block:  was 1992 and IDT  the last DSP BB? or Weitek?
8. EXAMPLES of Target AS-DSP
1. Analog programs (Basic, HPC and other gizmos)
2. TI C25 Tips and Tricks 
3. SPmag Tips and Tricks
4. 
   
2. BB Level 1
1. Arithmetic BB
2. Bit wise BB
3. Vector BB
3. BB1 DSP STRUCTURES
1. Processing trilogy (ALU, BMU, MULT)  
2. MAC
3. DAU
4. AGU 
5. PCU
6. RF (Register File) and MEM
7. VPU (Vector Processing Units)
8. SU (The Shuffle Unit) 
9. Bit slice: Bit slice building blocks
4. BB2 DSP FUNCTIONS
1. Filter
2. FFT
3. Correlators & bit comm. engines
4. Sampling
5. Matlab functions
5. BB3 MATLAB BB
6. BB4 MATH 
1. including Complex numbers
7. APPENDIX 

The Matlab Engine

The Matlab Engine

This is a piece of IP which is free and can be readily implemented in a fabric or FPGA. Even better, it could be already included; the same way than a Cortex core is included in a high end Altera FPGA.
Its purpose is to serve as an additional Cop to the target Cop.

For every pieces of m-code which could not be mapped, translated or compiled, the COP calls the
Matlab Engine.
Needless to say, it does not exist today.

Background                                                                                                                                  

In 2005, when Catalytic Matlab Accelerator/Compiler could not tackle an exotic Matlab construct, it would make "a call into Matlab". The reason is simple, Catalytic was an add-on to Matlab so we could always use its resources as needed. The big drawback was very poor performances since Matlab interprets the code.
Also since the last century The Mathworks offers a different type of Matlab engine called the MCR.
Oddly enough, the concept is simple to understand. You develop a demo in Matlab. How to show it to customers who do not have Matlab? simple, you 'rebuild" your demo with the MCR and delivers an executable to be run on the customer PC. This is an over-simplification of the process, but the point is made. Matlab exists as a x86 executable (say < 1G) which can be ported, hence it could be hardcoded.
Finally, this one is for me. Since i was a kid I made a point of honour at guessing April's fool jokes. But every 20 years or so I got really taken for a ride, especially if it is something "I knew they would be stupid enough to do that" Kind of Apple buying Tesla.
And so this year, Clever Cleve came up with a Matlab announcement: "the-matlab-watch".
http://blogs.mathworks.com/cleve/2015/04/01/experiencing-the-matlab-watch/?s_tid=Blog_Cleve_Category    Now, where he was really clever is that the platform was kind of realistic. He complained a bit about the lack of keyboard. Anyway he took me a few re-readings to realize it was a joke. Gosh, as John Updike said "an old cuckoo has always a second wind"

 The Near future: The Matlab Box                                            
It is obvious that there is niche market for a Matlab box. The problem is "is it bigger than Wall street?". Still, I would love The Mathworks to come up with something even if it is only a re branding operation. At worst they would piss-off a few ecosystem customers. Instead we have a myriad of analytics vendors and solutions, which is fair enough but has no interest for me, at least in this Blog.