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. 

T.O.C 20 May 2012

1. So you want to be a DSP architect?
1. The long story
2. Background Checks 
• Coprocessing
• Benchmarking
• BDT as an architectural tool
3. Building Block issues
4. Methodology and tools issues
2. Arithmetic BB
3. Bit wise BB
4. Vector BB
5. Math BB
6. DSP BB
7. Matlab BB
8. Found on the web
9. Stop me if you've heard this one before!
10. APPENDIX - DSP Architecture 
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)
11. APPENDIX - DSP structural Building Block
1. AGU 
2. PCU
3. DAU
4. SU (The Shuffle Unit) 
5. RF (Register File)
6. Bit slice: Bit slice building blocks

Bit Wise BB - an introduction

Bit Wise BB
This is  a heck of a topic!
Firstly it overlaps ISA studies  and DSP Building Blocks in at least 2 specific places (the DAU and the shuffle units).
Secondly, the variety of  function classes is very wide. For instance, pack/unpack, Count Leading Signs, Gallois Fields, bit manipulation.
Thirdly, and this will serve as an introduction to this topic, the function themselves can become amazingly out of hand. 
Finally, Matlab bit wise capability is limited or non coherent. As of this writing our latest bit wise library is floating point based!

Background                                                                                                                                  

In 1996, when we were designing the Tricore ISA, Bruce came up with a set of so called "permute" instructions and I do remember Rod's reaction as between bafflement and  irritation.
On Bruce side, the truth is that all Media processors had this class of instructions [ ref: search Ruby Lee].
On Rod side, we all know that the most precious resource in ISA design is the opcode. And, the biggest issue with bit wise instructions is that they are opcode hogs (always requiring dozens of control bits).
For the sake of the story, I would add that, since 1996 I have been involved with this issue multiple times and seen a few people falling in this trap.     

Example: TI C64+ : instruction PACKHL2                                                                                              
To illustrate this topic, we will now discuss in details the PACKHL2 instruction of the TI C64+ DSP.  We will then expand to all C64+ PACK instructions.

naming convention and syntax issue
The instruction mnemonic PACK implies that the destination register is smaller than the source register(s), HL is a subtype and 2 in the TI terminology means 2 sub-word operations. Since the registers are 32-bit wide,  ADD2 (sub2, etc.. ) will mean 2 x 16-bit additions, and ADD4 will 4 x 8-bit additions in parallel.

The syntax is
      PACKHL2(src1,src2, dst)   where src1,src2, dst  are all 32 bit registers

 Question: since he syntax is exactly the same as  
      ADD (src1,src2,dst)   where src1,src2, dst  are all 32 bit registers
why do you need the suffix 2?
Answer; In a 32-bit architecture, the 32-bit register is generic. All instructions use 32-bit registers. What matters are the operations inside the 32-bit registers. In this case 2 implies 16-bit data.
Question:  PACK implies some kind of register demotion. The syntax dst = src1 <op> src2 is just like any standard 2-operator syntax. The 2 registers are operated upon and the result is written to destination. Where is demotion in this type of operation?
Effectively, we would be more comfortable with   dst32= PACK(src64) where src64 is a 32-bit register pair (such as A3_A2). 
                         PACKHL A3_A2,A0       ; a syntax using a 32-bit register pair (64bit )  
                         PACKHL A2, A8, A0       ; TI syntax using  two 32-bit registers
but the advantage of the TI syntax is obvious: register flexibility.

Definition
We are now entering the core of the matter. What is the definition of the PACKHL instruction? First we want something simple to describe this instruction. Writing a "C" definition is rather wordy and the TI standard description is more complicated than needed.  The simplest description is to consider the 2 registers side by side, src2 on the left (made of the two half words D_C) and src1 on the right (respectively B_A), the result will be C_B.  
                      D_C B_A

                     C_B       

We have now the following definitions:
                        Z = concat(hi(X),lo(Y));    % hi() and lo() are self explaining functions
                        Z = [hi(X) lo(Y)];              % even more Matlab like
                        Z = [X(31:16) Y(15:0)];     not so Matlab

And they all look clear. But concatenation is not the same as packing. In fact, intuitively it is the contrary. One increase the variable size, the other reduce it.

Towards a general definition of PACK
Let us start with a most general definition. The register size is 64-bit and the granularity is 8-bit. Both values are very reasonable in 32-bit architectures.We will call this instruction PERM(ute).
                                      PERM(src64, dst64, controlword);
We will see later that PACKHL2 is just a sub-case of PERM.
PERM is easily described. as shown the following example

  src64   HGFEDCBA

         8x8 switch

  dst64   AAGHFEDC

In this description each  letter represents a byte and note the little endian choice.
But then what is the control word and how many bits do you need? The number of bits is the problem. In this case we have for destination a 64-bit register made of 8 sub-component (bytes). Each byte can receive any of the 8 source bytes (a 3-bit control) and since there are 8 destination bytes, the total number of bits is then 3x8= 24 bits. Not an easy decision to make in a 32-bit opcode! And using a register to hold the control word is a poor solution. It means a 3-cycle instruction (MVK, MVHK, PERM).
Finally the control word syntax is very straightforward. We just use the representation of the destination register.In the example above it is:
                              PERM(src64,dst64, AAGHFEDC)

Matching PERM and PACK

Using the similar definition to the one above, it can be seen that PACKHL2 is equivalent to:

                                         PERM(src32,src32,dst32, FEDC)
 In fact we can match all C64+ PACK Instructions in the same way (see table) 

It must be noted that the C64+  DPACK instructions are effectively more like PERM than PACK since the sources (combined) and destination have the same 64-bit width.


Conclusions

• Defining bit wise functions just by looking at the datapath is relatively easy and can give simple yet very powerful structures. Architects (attracted by elegance) will always love that.
• The problem is the control path which can become rapidly out of hand.
• To illustrate the problem we took an intruction from the C64+ instruction (PACKHL2) and extended it to a generic Permute instruction. The number of bits require to describe the instructions would be 24. 
• Thiis problem applies the same to a building block or a coprocessor unit. 
• With reference to the C64+ we will now compare the two approaches:
• Advantages of using a general PERM instruction
  
• Conceptually, it is very simple.
• Software implementation is very direct.
• Very flexible: any source byte can go to any destination byte. Any source byte can be duplicated (or replicated n times) in destination. 
• No need to do long studies and have drastic selection to choose the right PACK datapath to implement (this is very often the case with bytes). 
• C64+ offers only 2 choice: byte even and byte odd
•  Shortcomings for using a general PERM instruction
• Need 24 bits of control. This is not realistic in 32-bit ISA.
• C64+ defines only 8 instructions.The footprint is minimal
• Having 24 bits gives power(2,24) possibilities; how to test that? (by construction?)
• The flexibility advantage may be a delusion. Some features are missing. For instance, just looking at the C64+ ISA (sign extension, packing with saturation). saturation.
• While TI made the right choices for the C64+ ISA, a different situation (64-bit ISA, dedicated COP, etc..) might give different results.The astute reader, we are sure, has already plenty of ideas and solutions.
• BUT this is not the point of this section. The point is to make sure that you understand the main risk associated with Bit wise instructions (the control bits) . To be forewarned is to be ... 

  


 

SDR (Software Defined Radio)

SDR (Software Defined Radio)
This section covers an ambitious project. Let us imagine a wireless terminal made of 2 CPU blocks:  a powerful host armed with all media capabilities and a second block which can process any kind of RF signals and radio  protocols  (i.e 3G,4G, Wifi, gps, up to future standards such as cognitive radio). This second block is commonly called Software Defined Radio (SDR).

Background

The concept of SDR is as old as the radio [ref 1] but in our context we will put the burden on the solid shoulders of Les Mintzer circa 2000 [ref 2]. This was an FPGA implementation which makes a lot of sense as the money and impetus came from the military. In the same school see also Xilinx's Chris Dick, Spectrum's Lee Pucker and a few others [ref 3,4,5,6,7,8,9,10]. Now at this stage their implementation of SDR was far from fitting the definition but it made sense. Worse was to come. Firstly, in a brilliant case of taking the tree for the forest, a bunch of guys were using the PC/pentium as their example of SDR.They could do everything except radio.

Frankly first time I heard about that, I thought of genius generating radio from a PC  by using the EMC radiation of the chips, this sounds silly but after all this was the time of UWB so why not?

And then we had the usual silicon valley trend: a new buzzword for a new type of chip architecture [ref 11,12,13].

Reference

1. Dan Stransberg  " A century old technology enters the digital age", EDN , October 28 1999
2. Les Mintzer "Soft Radios and modems and FPGA" CSD mag, february 2000 p.52
3. Chris Dick, Fred Harris "the platform FPGA Software defined Radio" good paper but no reference, likely a conference circa 2001
4. Chris Dick "FPGAs cranked for software radio" EET, April 10, 2000
5. Chris Dick " A case for using FPGAs in SDR Phy" EET, August 12,2002
6. Lee Pucker "Paving Paths to SDR" csd mag june 2001 p.19
7. Lee Pucker, Systems Architect, Spectrum Signal Processing "Distributed Architecture for SDR" CSD 2001
8. Robert Sgandura PM Pentek " W221: Software Radio - From concepts to Implementation" likely at Communication System Design conference 2000 or 2001
9. Cord Finlay "Understanding SDR requirements" Wireless System Design July 2001
10. "Soft Radio key to universal applications" EE Times Special Report March 19, 2001
1. so full of hope, fortunately Loring Wirbel deflated the hot air in EET aug 12, 2002.
11. John Ralston "SDR emerges to address wireless industry needs" Wireless System design october 2000 
1. Describes the Morphics architecture
12. Armin Nueckel, Prashant Rao "The use of Reconfigurable Processor Arrays in wireless Infrastructure Systems" July 25, 2001 {white paper?} 
1. Describes the PACT architecture
13. Paul Master "the baseband solution for the worldphone" www.quicksilver.com 2001

DSP of the lost kind

DSP of the lost kind
The goal of this section is to laugh through the multiple attempts at defining new DSPs , next craze DSPs, further than DSPs, beyond DSPs , everything and their contrary as we went from 1995 to 2005 . Among the most notables we will have a quick pass at: Media processors.
Now, the obvious question is: why should we care? Once more, the answer is that there is a very large difference in use model between a  GP full market CPU and a COP.
What is ridiculous in one case becomes brilliant and  maybe most effective for the given application (see NVIDIA evolution). Also some of the brightest architects of  our time were involved in the design of these new machines. Finally this is still one of  the riches vein of ideas available publicly (but not freely) (IEEE, ACM, MDR, etc..). 

BACKGROUND

There are two reasons why we feel sad about this "Idiot Wind" period .

1. Too many people were getting carried away and too many arguments just did not make sense. 
1. For instance we computed it would take 1200 men years of application software (not tools)  just to meet the minimum requirements of fulfilling the claim of being a Media processor.
2. For a while, we went in the same direction, (and we have to thank the influence of Jim Turley for that) (mind you he changed his mind pretty quickly too).

DESCRIPTION AND TYPES

• Type 1
• Video Signal Processors
• Video DSP
• Media Processors
• Type 2  Legoland
• Multi IP DSP, Cluster Based DSP
• Bops, Cell, Improv, Equator
•  atsana, chipswright, clearspeeed, craddle, e-lite, powerFFT, sandbridge, siroyan, synputer, telairity, tops, trips  
• Infinite-tech RADarray  (neil stollon ICSPAT 99)
• RADarray of RADcore coprocessors connected to host
• Host and peripherals are 3rd-party IP
• Each RADcore is a reconfigurable stream algorithm coprocessor.
• Each RADcore is made of user selected Execution Units (EXUs) interconnected by reconfigurable data path bus architecture
• EXUs form independent elemental processing blocks such as ALUs, MACs, memories, I/O,etc..
• Type 3 Domain DSP
• Wireless DSP,
• Speech, Audio DSP
• Broadband DSP
• Custom DSP, configurable DSP, 
• Reconfigurable DSP
  

Media Processor (MP) (or MVP) (V for Video)

Born around 92-94, the  MVP had a peak around 1997, went through multiple "down and up"s before final death by 2005.The most famous (first wave) names were TriMedia, MicroUnity, Chromatics, NVidia [ref.1]
They had several characteristic in common:

• It was a new type of processor (the MEDIA processor)
• from our DSP perspective it was a bit baffling. Why not use a DSP?
• They were the latest incarnation of the MultiMedia (MM) craze.
• very soon followed by MM extensions. Compare MP and MM extension
  
• For some reasons most were based on VLIW.
• Why?
• While 5 of 7 MM functions could be done by a DSP,  they rightly believed that a DSP would not be able to do the last 2 (video and graphics). 
• But then why do they think they could?
• What were the 7 functions?
• Finally, the most obvious characteristic was their disdain for the Pentium. In a typical Silicon Valley Fashion, after loosing the Risc war, that was the new  frontier.In a nutshell:
• First they lost the PC seat to the Pentium (that was CISC versus RISC)
• Then they (re lost) the PC MM seat to the Pentium (that was GP processor versus Media processor)
• Finally they could not even find a small coprocessor seat in the PC, i.e. to be used as a Media COP!!
• This is the point which merits attention. See NVIDIA below
• In their final days, to add insult to injury they were totally inadequate for the embedded market. 
• Mind you, good luck trying DVD in 1999 or cell phone in 2000 with a 288 bit wide opcode and no software support!

NVIDIA
In the most remarkable feat of the century, NVIDIA changed direction by focusing on graphics instead of a rainbow of applications [ref.2].
       Not sure about their recent direction towards general purpose, people never learn it seems!
TriMedia
In another example of adaptation, the champion of VLIW, after years of trying software optimization instead redesigned their chips with two multiple powerful video coprocessors. Also important, Phillips concentrated on platforms and Trimedia became "the other core" of the Nexperia platform. Instead of ARM+DSP it was MIPS+TriMedia. Mind you, the latest instantiation of the platform could be ARM + COPs.
Definitely a good DSP core, the TriMedia  was a relatively simple 5 issue machine, had some neat tricks (fusing of  operations at the register file ports) and very eearly code compression. [ref 6,7,8,9]
MicroUnity MediaProcessor
Original coiner of the term, famous for John Moussouris, MicroUnity was the first on the scene and the first to die; they set the architecture standard for a single core parallelism pretty high. [ref 10,11]. They had a following with Equator.
Chromatics MPACT
The other Media Processor, noticed for its 792-bit datapath (if today it sounds peanuts, at the time the standard was 64-bit)... currently dead. [ref 12]
Offer from the East
As can one expect, Japan and its all powerful integrated consumer industry were not the last to follow the hype with their own offering
- Sharp DDMP (1997)
- NEC MP98   (MPR March2000)
- Toshiba MEP (after giving up MPACT) (EPF 2002)
- Fujitsu (was their VLIW a Media Processor?)
- Hitachi ??
- Matsushita ??
Among the Noise
While not serious commercial products, the MVPs developed by Universities and Research labs had interesting features. These are 2 examples we were familiar at the time but there are litteraly 100s of them [ref 13,14].

• University of Hannover HiPAR  {search Johannes Kneip} (IEEE Video for Circuit and systems 1996)
• Impressive X,Y memory
• Infineon VIP {search Uli Ramacher} (Hot Chips 13) 

Finally the true MVP
The TI C80 also known as MVP (1993) remains an excellent architecture example. It is NOT a Media processor. Its was designed like any other DSP, with an ambitious target in MIPS which happened to be  video conferencing. Now as part of the strategy obviously the target was anything in the same order of MIPS magnitude. Most interesting it was a host+4xDSP core solution. Even more: how can you be so wrong in the memory model? (refer to somewhere else in this Blog). 

Lessons Learnt

NVIDIA
Headline1: MultiMedia processor becomes UniMedia processor.

Headline2: Media processor becomes Graphics solution..
And they had enormous success as Pentium "Coprocessor" .
Now this is an important lesson, for co-processing.  As a general purpose co-processing MM chip, the MVP architecture was a complete failure. As a "very focused" co-processing solution point, it is part of the standard PC architecture. 
Microunity, Chromatics, TriMedia
It would be silly to forget these architectures. On one hand, more recent and better architectures have been developed but on the other hand they are not so visible. 
Further: the GPU story
Obviously these are still questions (we have to wait another 3-5 years to learn the lesson):
- KEY: is there a place for another type of computing (the GPU)?
       One has to bear in mind that in 40 years of  silicon computing  (except for a short time of DSP) all attempts to compete with the general purpose model ended up in abject failures.
- what kind of the processing model is the dual head(CPU+GPU) adopted by AMD ?
- in the same way, what kind CPU+GPU is the Apple model?
 

References

1. John.A.Watlington "Video signal processors" , circa 1997, http://wad.www.media.mit.edu/peole/wad/vsp/node1.htm from a web site which (as usual) has gone pining for the woods. Too bad , it contained an excellent and succint table of comparison.
2. Section news" NVIDIA changes direction" EBN December 23,1996 issue:1038 
3. Bernard Cole "New processors up multimedia's punch" EET February 3, 1997.
   8. Lee, W., Kim, Y., Gove, R.J., and Reed, C.J., “MediaStation 5000: Integrating Video an
1. it is more the answer from CPUs (MM extensions) to MM processors.
4. Jim Turley "Multimedia chips complicate choices" MDR Feb 12, 1996 page 14
5. Maury Wright "Media Procesors target digital video Roles" EDN  sep 1, 1998
6. Tom Halfill "Philips Trimedia goes Mobile " MPR dec 5, 2005 
7. Gert Slavenburg and his biking pal "DSPCPU operations for TM1100" 1999, Appendix A, Preliminary information
8. Gert Slavenburg, etc..'Custom operations for Multimedia" Chapter 4 of the same reference
9. Peter Clarke " Compressed VLIW meets multimedia" EE Dec, 1995
10. Craig Hansen "MicroUnity MediaProcessor Architecture" IEEE micro, 1996
1. quote "A broadband mediaprocessor extends and streamlines a general-purpose computer system to attain the goal of communicating and processing digital video, audio, data and RF signals (SIC!) at broadband rates using compiled, downloadable, software rather than special-purpose hardware. The instruction set, system facilities, and initial implementations of an architectural family of broadband mediaprocessors are introduced, and compiled software development is illustrated with an example and description of the development environment".
11. John Moussouris (easy to remember mouse+souris) "A roadmap of the Mediaprocessor Design space" Microdesign Resources Dinner May 9, 1996
12. Yong Yao " Chromatics's Mpact2 boosts 3D, MPR Nov 18, 1996
13. SSC 27 12, dec 92 p1886
14. SSC 29 12, dec 94 p1474
15. http://www.cse.fau.edu/~borko/Chapter21_mc.pdf
1. Just added this morning, just wished I had  read it before.kind of complement to our MM splash. Hey Borko is it public? 

Answer to questions

The 7 functions:

• graphics including 3D
• video (compression, editing , conferencing)
• high quality Audio
• computer telephony, Speech
• communications, Fax, Modems
• real time 3D games
• DVD?

COP - DSP FUNCTIONS

DSP Functional Building Blocks
The goal of this section is to cover the history of long story DSP functional blocks. As its name implies, this type of block is opposed to DSP structural block such as (bit/byte/word  slice logic).  

BACKGROUND

Let us give a special mention to the CAFIR (a FIR filter from motorola 1986) and the C66xx FTT Engine (TI 2010) and to our friends of the Morphics Next Gen.

LIST OF FUNCTIONS

• Filters
• including equalizers
• FFTers
• bit reverse (!!)
• Convolvers
• Bit convolvers and Gallois field arithmetic
• Hats off to unsung heroes of 30 years of custom DSP (see for instance ISSCC 1980-now)

FILTERS

DSP56200 also known as CAFIR (Motorola 1987)  [ref. 1]
- Main function is adaptive filtering using LMS .
- 256 x 24-bit coef RAM
- 256 x16-bit data  RAM
Can be configured as single FIR, dual FIR or Single adaptive FIR
Programmable loop gain in adaptive Mode
Programmable coef. leakage term.

REFERENCES

 

1. Motorola " DSP56200  data sheet", 1988,also called ADI1257R1
2. Hossein Yassaie  "Digital filtering with the IMS A100" Inmos 1986
   
3. FUJITSU " MB86795 data sheet" ,  aug 1987
4. Atmel "ATC 76C001 programmable FIR filter", 1996
5. Amphion " Cascadable FIR", Quicklogic, 2001
6. ISS "Biquad IIR filter megafunction" Altera, 200
7. see Xilinx, Altera etc.. Catalogues
8. Jordan, mannock "Correlation-function, peak detector",  IEE Proc., March 1981
9. Tao Lin, Dahn Le ngoc" Implementation of digital filters using IDT7320, IDT7210, IDT7216, and IDT7383" IDT A.N  AN-32, 1990