1.3 Building Block Issues

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

1. Naming conventions
1. Example: addsub21 
2. The Philosophy of BB
2. Matching functions to structure

Naming Conventions

The biggest of all BB issues is strangely enough the organization and naming convention. For people familiar with software libraries this is a trivial problem but for people designing chips, or instruction set, or say building block for a FPGA library  this can really turn into a nightmare.
So the right attitude is not underestimate this problem but do not spend much time on it (*)

• The best BBs have 8 letters or less.
• Have a naming convention from the beginning  and STICK TO IT.
• Expect this naming convention to become dirtier as time goes by. As you design more and more final products, there is obviously positive  feedback trickling down to the lower level and that means redesigning the block and giving a derived name. Such as a 3 input adder working on on vector of 72 packed bytes called ADD31_PBV72, becomes ADD31_PBV72A or PBV721 or PBV72v2; bottom line it complicates your nice naming convention.
• Expect this naming convention not to be universal; when a BB (between 1 and 10%  will) not fit the naming convention; just call it Jack, jojo or Kapernic.
• Instead keep an updated excel with a minimum of characteristics for all designed (and planned) BBs. This is a real pain, but it is necessary. you cannot judge a BB by its name. As I will show in an example ADDSUB can literally have more than 100 definitions.
• Any automatic method helps but in all cases it means human reviewing since you must at least know what you have in stock. Remember that you are a designer not a user.
• As you go up the food chain, naming conventions must change from a description (MUL16x32) to a catalog entry (DSP5400).
• There are functional blocks which as least should have the name of the function (FFT). And also can be both descriptive and catalog. Hence FFT16x32 is nice but then what about final result is it 16 or 32? do you use rounding? bit reverse? in place?  Very soon you adopt the catalog attitude such as FFT1, FFT2, etc..
• Parametrized blocks help but are costly in description, hardware, testing and software.
• A good solution is the concept  of toolkit and build. To have a toolkit ready such as new blocks are built, tested and DOCUMENTED only when needed.
• I strongly recommend to use a meaningful name for every build and not the automatic conventions found in software versioning. Firstly we are speaking about generating different BBs, not different versions of the same BB. Secondly a BB is by definition simple. It is bounded in functionality, input and output. This is not the case of software.

Example of building block: addsub
In this example, we are showing how even simple function can rapidly come out of hand. First let us start withe name. My naming convention is based on 3 fields: functionName[IO pins][arithmetic scheme]_[data type]. So for instance :

In this case we will use the Matlab default (FP) which has also a default arithmetic scheme and we will call the component addsub22 such that:

function [Z W]=addsub22(X,Y)                                         Z= X+Y;

  W= X-Y;
end

So far so good. So what can go wrong with the definition? Before we continue, it must be noted that this is NOT the most popular definition. The popular definition has 4 inputs and consists of two independent add and a sub in parallel. This is okay since using our naming convention it would be  

function [z w]=addsub42(x,y,u,v)

    z= x+y;

    w= u-v;

end

The Data types
Using (b,s,l) hungarian convention we define the 3 signed integer components:
   function [bZ bW]=addsub22_b(bX,bY)   % int8

   function [sZ sW]=addsub22_s(sX sY)     % int16
   function [lZ lW]=addsub22_l(lX,lY)       % int32
We can use standard Matlab FP to define these components. It is a bit wordy since we must write the code for casting FP to integer and also FP does not offer 64-bit precision.

The alternative is to use the the Matlab "integer" type (int8,int16,int32)  but it does not cover all Matlab functions (complex numbers) and it offers only 1 arithmetic scheme(sat).

The modals (arithmetic schemes)
How to indicate the modals? Contrary to popular beliefs theye are NOT 2 (modulo, sat) but 3 (modulo, sar, promoted). Promoted is the integer equivalent of FP. As the data grows so do the output.
function [sZ sW]=addsub22m_s(sX,sY)   % if ovf, results are wrap around
function [sZ sW]=addsub22s_s(sX,sY)   % if ovf, results are saturated 
function [sZ sW]=addsub22p_s(sX,sY)   % output is 17-bit so there cannot be ovf;
!) note that the hungarian notation is plainly wrong for the promoted outputs.
!!)  and the "p" scheme not precise enough; output could be 32 bit (standard in CPU)


A vast and  unfriendly territory is the Fixed Point data type (FXP). 
Developing an FXP algorithm in Matlab native type (FP) might be faster than for integer, So the difficulty is not there.Moreover Matlab offers its own FXP language which is natively based. 
The complexity comes from multiple misconceptions with FXP (not covered here). 
Here is the code
 function [z w]=addsub22_q(x,y,qpoint)
   t= plus(x,y);    
   z= qformat(t,qpoint);   
   t= minus(x,y);    
   z= qformat(t,qpoint)  

Note that code is flexible enough to take any q format and even integers. An int16 is defined as16q0 and an int32 as a 32q0. 
But  there are also serious limitations. Matlab FP (double) is limited to around 43 bits of precision. That does not fly well for 48-bit accumulators (or a 108-bit accumulator as I saw on a recent piece of DSP IP). 
Also there is no casting in inputs, only in outputs. Hence the basic arithmetic scheme is FP (promoted). 
Finally there is no concept of unsigned here.

Another vastly uncharted territory is sub-word parallelism(SWP)
Also called Packed arithmetic or more commonly called SIMD  or whatever marketing Pentium extensions, sub word parallelism (SWP) is a very powerful BB technique which cannot be ignored.
Matlab offers inherent parallelism, shapeless operators, packing and predication flags which makes it a good match for SWP. 
But in the example I will show the difficulties of SWP.
If we take the BB called addsub42, its SWP version becomes addsub21 such that:
function z_w= addsub21(x_u, y_v)
  z= extract_left(x_u) + extract_left(y_v);  
  w= extract_right(x_u) - extract_right(y_v);  
  z_w= pack(z,w);
While this code is essentially correct, it is not useful. There is still too much vagueness to be used as specs.

References

Foot notes

(*) not like my friend Klaus who started a war on verilog naming convention):