home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10434 < prev    next >
Encoding:
Text File  |  1992-11-06  |  2.3 KB  |  53 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!ukma!nntp.msstate.edu!nntp.msstate.edu!linder
  3. From: linder@ERC.MsState.Edu (Dan Linder)
  4. Subject: Re: asynchronous DSP project at Berkeley
  5. In-Reply-To: "Carl Bruggeman"'s message of Tue, 27 Oct 1992 11:52:01 -0500
  6. Message-ID: <LINDER.92Nov5175441@desperado.ERC.MsState.Edu>
  7. Sender: news@ra.msstate.edu
  8. Nntp-Posting-Host: desperado.erc.msstate.edu
  9. Organization: /home3/linder/.organization
  10. References: <1992Oct27.115210.14352@news.cs.indiana.edu>
  11. Distribution: na
  12. Date: Thu, 5 Nov 1992 23:54:40 GMT
  13. Lines: 38
  14.  
  15. >   In article <1992Oct27.115210.14352@news.cs.indiana.edu> "Carl Bruggeman"
  16. >   <bruggema@gable.cs.indiana.edu> writes: 
  17.  
  18. >   I vaguely recall a reference made on this news group several months ago
  19. >   to a group at Berkeley working on a DSP using asynchronous design
  20. >   methods.  Does anyone have a reference to the work done by this group?
  21.  
  22. You might try:
  23.  
  24.   G. M. Jacobs and R. W. Brodersen, "A Fully Asynchronous Digital Signal
  25.     Processor Using Self-Timed Circuits," IEEE Trans. on Comp., vol. 25,
  26.     no. 6, Dec. 1990, pp. 1526-1537.
  27.  
  28. Martin also has a processor described in:
  29.  
  30.   A. J. Martin, S. M. Burns, T. K. Lee, D. Borkovic, and P. J. Hazewindus,
  31.     "The Design of an Asynchronous Microprocessor,"  Advanced Research in
  32.     VLSI, Proceedings of the Decennial Caltech Conference on VLSI, March
  33.     1989, pp. 351-373. 
  34.  
  35. >   I am particularly interested in why they chose a DSP rather than a
  36. >   general purpose CPU.  I suspect the answer is that the complexity of the
  37. >   global state machine controlling a typical RISC pipeline (and in
  38. >   particular exception handling and interrupts) is overwhelming for any of
  39. >   the current asynchronous design methodologies.  Am I wrong?
  40.  
  41. Brodersen is well known in the DSP area so this probably influenced their
  42. decision.  It is interesting to note that the DSP processor uses
  43. microprogramming and Martin's processor only has a few instructions.  I
  44. suspect as well that the complexity of a modern RISC control unit is beyond
  45. current asynchronous techniques.  Are there any asynchronous methods that
  46. can efficiently combine the generation of a multitude of control signals
  47. while also making the complex logical decisions associated with big state
  48. machines?
  49.  
  50. Dan Linder                               
  51. linder@erc.msstate.edu
  52.  
  53.