HDTenEightyP/NetNews huggingface dataset:
From: njain@bnr.ca (Narendra Jain)
Subject: Info on analog behavioral modelling wanted
Originator: njain@bcrka342
Keywords: analog, modelling, CAD
Organization: Bell-Northern Research, Ottawa, Canada
Date: Tue, 18 Aug 1992 00:24:48 GMT

I am looking for published papers, books, articles, notes or any
sort of information dealing with modelling of complex analog blocks
such as ADC, PLL and DISDM behaviorally for use with a simulation
tools for verification.

There is a lot of published literature for the "design" of these
blocks. Does anybody know of "design-system" or CAD related issues?

Thanks in advance for your help.
------------------------------------------------------------------
Narendra Jain (5S53)   	ESN:   (393) 3103	185 Corkstown Rd.
Bell Northern Research	Phone: (613) 763-3103	Nepean, Ontario
email: njain@bnr.ca	Fax:   (613) 763-7241	K2H-8V4 CANADA
------------------------------------------------------------------
Newsgroups: comp.lsi
From: nestor@iitmax.iit.edu (John Nestor)
Subject: VLSI Design Course at IIT Rice Campus, Wheaton
Organization: Illinois Institute of Technology / Academic Computing Center
Distribution: chi
Date: Wed, 12 Aug 92 21:19:17 GMT


		   ILLINOIS INSTITUTE OF TECHNOLOGY
		      Daniel F. and Ada Rice Campus
			   201 E. Loop Rd.
			  Wheaton, Illinois

			 EE 530 - VLSI Design
			      FALL, 1992

Instructor:	Professor John A. Nestor
Phone: 		(312) 567-3386
E-mail: 	jnestor@salsa.iit.edu
Lectures:	Tue.,Thu.  5:00-6:15	Rice Campus and IIT/V

OBJECTIVES

The objective of this course is to provide the student with an
understanding of the capabilities and limitations of VLSI CMOS
integrated circuits.  The course will cover the basic technology of
CMOS VLSI and techniques for designing chips with this technology.
Topics will include: MOS transistor theory, VLSI processing, layout
design rules, layout analysis and performance estimation, the use of
computer-aided-design (CAD) tools for layout design, system design,
and Application-Specific Integrated Circuits (ASICs).  Students will
create, analyze and simulate a number of small circuit layouts as
homeworks, culminating with a term design project as described below.

The course will be taught at the Daniel F. and Ada Rice Campus, which
is located in the western suburbs of Chicago near the intersection of
Butterfield Rd. and Naperville-Wheaton Rd.  It will also be broadcast
to all IIT/V remote sites, including the IIT Downtown Campus, AT&T,
Motorola, Northrop, and several other locations througout the suburbs.

PROJECT

To gain design experience, students will design a small chip and
simulate the design for correctness.  Since chip design requires the
use of CAD tools, access to tools will be provided on workstations at
the IIT Rice Campus in Wheaton and the main campus downtown.  Students
with access to UNIX workstations (e.g. SUN, DEC) at their work sites
can obtain tools for installation at their site.  Contact the
instructor for more details.

PREREQUISITES

Graduate standing and a thorough understanding of basic logic design
(EE 228 or equiv.).  Advanced undergraduate students may register for
this course with permission of instructor.

TEXTBOOK

1.	N. Weste and K. Eshraghian, Principles of CMOS VLSI Design,
	Addison-Wesley, 1985.
2.	Notes distributed in class

For more information, contact the instructor.
-- 
John A. Nestor				...spl1!iitmax!nestor
ECE Department				nestor@iitmax.iit.edu
Illinois Institute of Technology
Chicago, IL 60616			(312) 567-3386
From: holen@xilinx.com (Victor A. Holen )
Newsgroups: comp.lsi
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Date: 20 Aug 92 22:29:35 GMT
Article-I.D.: xilinx.1992Aug20.222935.22380
Organization: Xilinx Inc.

In article <> orpheus@reed.edu (P. Hawthorne) writes:
>
>  Graph theory is at the heart of so many fields that it is somewhat
....
>  I'd be interested in hearing from others, to see if a more formal
>approach to creating such a newsgroup is warranted.

You may want to subscribe to the related listserv groups, e.g:

GRAPHNET    GRAPHNET@NDSUVM1  GRAPHNET - Graph Theory
GTPEOPLE    GTPEOPLE@CUNYVM   GTPEOPLE: Graph Theory Researchers Directory
GRAFOS-L    GRAFOS-L@UFRJ     GRAFOS-L Aspectos matematicos e computacionai
MIMUW-L     MIMUW-L@PLEARN    Affairs of Warsaw U. Fac. of Math., Informati
TECHMATH    TECHMATH@TECHNION TECHMATH - Technion Mathematics Net
ALLIANCE    ALLIANCE@NCSUVM   North Carolina Science and Mathematics Allian

-- 
 victor ....  ___  ._..  .  _.     holen@xilinx.com
From: alex@rolls.dsp.hellnet.org (Alexander Meidel)
Newsgroups: comp.lsi
Subject: Off-chip circuits problems
Keywords: VLSI
Date: 12 Aug 92 09:06:34 GMT
Followup-To: alex@dsp.hellnet.org
Organization: DSP Semiconductors, Israel.


 Hi!

  I am a circuit engineer. I make design of off-chip drivers, 
reciever circuits, using ready Input PAD Protection.
I have a problem when power supply of chip - 3.3 v, and the 
high level of input sygnals is 5 v. The problem is how to
reduce input sygnal ( level shifting ) to 3.3 v inside the 
chip in the area of Input PAD Protection. I am afraid of 
parasitics bipolar transistors or  lacht-up or punchthrough 
problems.
Is the simple transfer gate on n-type transistor good solution ?


Thank for advance.

----------------------------------------------------------------


                                           |    _    _  _
     /\       _  -                         |   | \  /   | \ 
  - /\ \/|\/||_|/ \                        |   |  | |_  |__|
  \/--- \|  ||_/\_ |                       |   |  /   \ |  
                                           |   |_/  __/ |
If at first you don't  succeed,            |
redefine success.                          | 
   -- Dick Brandon                         |
________________________________________________________________
Newsgroups: comp.lsi
From: keithl@klic.rain.com (Keith Lofstrom)
Subject: Re: Die aspect ratio.
Organization: Keith Lofstrom Integrated Circuits
Date: Sun, 16 Aug 1992 08:56:41 GMT

In article <16erivINNfir@agate.berkeley.edu> krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>
>It seems unlikely that an irregular design such as a processor or
>cache controller would map naturally to a square die floorplan.  Is
>there some inherent yield or manufacturability advantage to having a
>square die?  I can think of reticle size and maybe efficient wafer
>tiling as two reasons.
>
>Rectangular die give more perimeter per unit area if a design is pad
>limited. What's the largest sensible/known aspect ratio? (We've done
>one processor die with an aspect ratio of 2.3:1).

If a die is core limited, a square die will be the most efficient.  Wafer
tiling is more efficient, as well.  The photo process is better towards
the center of the reticle, and a square die will yield and align better
than a rectangular one, due to accumulated errors along the long axis
of the die.

In some cases, due to step field size, cad tools, probe card limits, etc,
it is difficult to make one dimension larger than a certain size.  This 
means large die tend to be square.  Also, some aspects of driver design
are easier if you have to do calculations of wire length, etc, for one 
side dimension rather than two.  

Most standard open-tool packages are designed around square die, and with
minimum wirebond lengths of 20 mils and maximum wirebond lengths of 120 mils,
a die with more than 200 mils difference in side lengths will need a custom
package.  Even within the 200 mil limit, the long bond wires will be more
inductive on one side than the other, leading to more design work.

My last two projects were perfectly square, into a square package.  I 
worry about assembly mistakes (accidental rotation of the die) though
worst case we just grind a new pin 1 mark on the plastic package, or spec
4 different varieties  ;-).

The largest aspect ratio I have heard about were some Reticon CCD linear
imaging arrays - these were quite long and skinny.  Tektronix made some CCD
waveform sampling arrays that were pretty long, but those had to be wide
enough so they wouldn't fall apart during scribe and break.  I ran an Explorer
Scout group that used some of the "left-over" width for some student test
projects - high school kids designing tiny (200 gate) digital circuits,
kinda fun.

Keith
-- 
Keith Lofstrom         keithl@klic.rain.com       Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Power ICs
Newsgroups: comp.lsi,comp.lsi.cad
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Subject: Re: Multiported Register Files
Date: Sat, 15 Aug 92 17:08:21 GMT
Organization: Netcom Online Communications Service

There is a paper, referenced below.  Its title calls it
a "Seventeen Port Register File" and that is true, the file
as a whole has seventeen ports.  However, eight of those
"ports" are dedicated paths to dedicated registers.  No
individual register has more than nine ports.

Further, they do the standard maneuver of splitting
the clock cycle into two phases and time-multiplexing
the wires which implement the "ports":  During one
half of the clock, three writes can take place, and
during the other half of the clock, six reads can
take place.  So if you wanted to, you could say the
cell was "six ported and double-clocked".

As you have probably figured out, from the fact that
there are twice as many read "ports" as write ports,
the circuit design performs writes differentially but
reads single-ended.  Which places additional constraints
upon the normal tradeoff of (number of registers) versus
(cycletime).  Since the original poster's address
is from a ".EDU" domain, I'd urge them to study
the differential-read versus single-ended-read design
problem; you'll learn something about the sort
of design decisions that industrial practicioners
are faced with routinely.

It all seems to work, as evidenced by the fact that
the commercial product embodying this design, is
selling well in the marketplace and apparently
working just dandy.  It's the Intel i960 (with a Nine)
microprocessor.

  R. D. Jolly, "A 9ns, 1.4 Gigabyte/s, 17-ported CMOS
  Register File", IEEE J. Solid State Circuits, Vol. 26,
  No. 10, October 1991, pp. 1407-1412.


-- M. Johnson
Newsgroups: comp.lsi
From: jon@alpha.ee.ufl.edu (Jon Mellott)
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Organization: EE Dept at UF
Date: Tue, 18 Aug 92 12:53:12 GMT

In article <1992Aug18.084810.26862@reed.edu>, orpheus@reed.edu (P. Hawthorne) writes:
|> 
|>   Graph theory is at the heart of so many fields that it is somewhat
|> obscured by its own versatility.
|> 
|>   I feel that there ought to be a graph theoretic newsgroup, if only for
|> the insights that such a multidisciplinary newsgroup could offer.
|> 
|>   I'd be interested in hearing from others, to see if a more formal
|> approach to creating such a newsgroup is warranted.
|> 
Gee, I seem to find myself sounding like a broken record, but here goes...

The traffic on this newsgroup does not warrant the creation of a spin-off 
newsgroup. I don't recall ever seeing any discussion of graph theory in 
this newsgroup (I could be wrong) so I don't see that there is a need. 
Why don't you try to get some discussion on graph theory going on this 
newsgroup. If the volume gets annoying then maybe it will warrant the creation 
of a new newsgroup.

BTW, have you read comp.lsi.testing lately?  :)

Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
From: orpheus@reed.edu (P. Hawthorne)
Newsgroups: comp.lsi
Subject: A Graph Theory Newsgroup, Perhaps?
Date: 18 Aug 92 08:48:10 GMT
Article-I.D.: reed.1992Aug18.084810.26862
Organization: Reed College, Portland OR


  Graph theory is at the heart of so many fields that it is somewhat
obscured by its own versatility.

  I feel that there ought to be a graph theoretic newsgroup, if only for
the insights that such a multidisciplinary newsgroup could offer.

  I'd be interested in hearing from others, to see if a more formal
approach to creating such a newsgroup is warranted.


  Theus (Prometheus Hawthorne - Jones, orpheus@reed.edu)
Xref: sparky comp.lsi:557 comp.lsi.cad:893 comp.ai.neural-nets:3270
From: lazzaro@boom.CS.Berkeley.EDU (John Lazzaro)
Newsgroups: comp.lsi,comp.lsi.cad,comp.ai.neural-nets
Subject: Chipmunk CAD Tool Users -- Please Read This Message
Date: 22 Aug 92 01:15:34 GMT
Distribution: world
Organization: University of California at Berkeley
NNTP-Posting-Host: boom.cs.berkeley.edu


        I'm working on an updated distribution of the Chipmunk tools,
adding in bug fixes, ports, and new features from contributors. The
package is a few months away from being "ready for the world" --
please don't ask me to send out copies yet. Below is a list of all the
additions that I have been sent by people; I'm posting this list for
two reasons:

1)Maybe you sent me something over the past two years and I lost it;
if your name isn't on the list and you sent something, you should
send me email and tell me what you sent.

2)Maybe you have some bug fixes/ports/additions to some tool in the
Chipmunk toolset; if so, this is a call to send them to me so I can
add them.

        Thanks to everyone who has sent things in!

                                                --john lazzaro
                                                  chipmunk maintainer
                                                  lazzaro@cs.berkeley.edu


Ports:
-----

DEC Mips:      Marwan Jabri (Sydney U) and Tor Sverre Lande (Oslo)
HP series 800: John Lemoncheck (Caltech)
IBM RS/6000    Gary Liu (Caltech)
A/UX           Gary Stafford (Apple) and Mike Godfrey (Stanford)
Apollo         MaryAnn Maher (ETH)
OpenWindows    Harry L. (JPL)

Additions
---------

Spice support  Harold Levy(Caltech)
New FET model  Bhusan Gupta(Caltech)  
Newcrt popup   Gary Stafford (Apple)
 windows

Bug reports/fixes
-----------------
View measure    Tommy Tucker(Boeing)
 mode
Wol drc.out     Tobi Delbruck(Caltech)
 bug
Netcmp identify (Caltech)
 mode bugs
Lplot circuit   (Caltech)
 diagram zoom
 mode bugs
Wol extract     (Caltech)
 bugs
Until           (Caltech)
 edit-extent
 mode bugs
From: luciano@athos.Berkeley.EDU (Luciano Lavagno)
Newsgroups: comp.lsi
Subject: Re: Query : Estimating size of cubes in cube cover.
Date: 17 Aug 92 17:12:21 GMT
Reply-To: luciano@athos.Berkeley.EDU (Luciano Lavagno)
Organization: UC Berkeley IC CAD Group

In article <9208111010.AA15042@kailash.cse.iitb.ernet.in>,
pagey@kailash.cse.iitb.ernet.in (S Pagey) writes:
>The basic technique used in two level minimization of single output Boolean
>functions is to find a cube cover of smallest size. My querry is about the
>estimation of the sizes of cubes in the cube cover. The querry is,
>
>Given the assignment of 0, 1, and X (don't cares) to the vertices, how to
>estimate sizes of cubes in the cube cover, without actually finding the cube
>cover? Are any bounds known on the sizes of cubes in cube cover? The cube
>cover
>referred to here is same as the cube cover for two level minimization of
>Boolean functions. 

What do you mean by "sizes of cubes" ? The number of vertices covered by each
cube ? Moreover, the cover is by no means unique... even if you limit yourself
to prime and irredundant covers.
So it seems that I need more information in order to help you...
Luciano
P.s. sorry about the delay: I tried to reply by e-mail, but it bounced back
after a week of fruitless attempts...
-- 
Luciano Lavagno            luciano@ic.Berkeley.EDU            +1-510-642-5012
Dept. of EECS, 207-69 Cory Hall, Univ. of California, Berkeley, CA 94720, USA
Xref: sparky comp.lsi:560 comp.lsi.cad:897 comp.dsp:1989
From: inyup@python.icsl.ucla.edu (Inyup Kang)
Newsgroups: comp.lsi,comp.lsi.cad,comp.dsp
Subject: PIPELINED IIR(RECURSIVE) STRUCTURE?
Date: 22 Aug 92 20:55:10 GMT
Followup-To: comp.lsi
Organization: UCLA Integrated Circuits & Systems Laboratory

Do you know how to increase the throughput rate of the
IIR filter (or any RECURSIVE structure)?

I know that somebody do this(e.g. Parhi: SCATTERED LOOK-AHEAD....,
SIGNED DIGIT COMPUTATION WITH NO CARRY.....).

For my purpose, the LATENCY is ok(same situation as the PIPELINED FIR filter).

Please tell me about old or new idea?

(Actually, I come up with new idea, so I want know somebody do same approach.)


- Inyup Kang
From: andrea@esp.ics.uci.edu (Andrea Capitanio)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Multiported Register Files
Summary: Do anybody knows anything about multiported SRAMs with more than 6 ports ?
Keywords: Register File, SRAM
Date: 14 Aug 92 20:17:06 GMT
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.

I'm wondering if anybody out there is aware of any implementation
of multi-port static memories with large (i.e., >= 6) # of ports
or if any reference to the topic exist.

Thanks,

A. Capitanio,
UC Irvine.
--
Andrea Capitanio
From: pak@cse.ucsc.edu (Pak K. Chan)
Newsgroups: comp.lsi
Subject: CFP: 11th Computer Arithmetic Symposium
Date: 17 Aug 92 18:21:04 GMT
Distribution: world
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: pico.ucsc.edu


                            ARITH 11

           11th IEEE SYMPOSIUM ON COMPUTER ARITHMETIC

                     June 30 - July 2, 1993

                    Windsor, Ontario, CANADA


                         CALL FOR PAPERS


Authors are invited to submit papers describing  recent  advances
on  all  aspects  of computer arithmetic, including, but not res-
tricted to the following topics:

   Foundations of number systems and arithmetic;
   Arithmetic algorithms and their analysis;
   Arithmetic processor design and implementation;
   Highly parallel arithmetic units and systems;
   New floating point chips, boards and systems;
   Standards for number representation and arithmetic;
   Impact of high level languages on arithmetic systems;
   Special function implementation; and
   Reliability and testability of arithmetic systems.

Four (4) copies of the complete paper should be submitted to  one
of the three Chairs no later than November 1, 1992.  In addition,
information about the paper (title, authors(s) and topic)  should
be  sent, either by e-mail  to jullien@engn.uwindsor.ca or by FAX
to Dr. G.A. Jullien, Dept. Electrical Engineering, University  of
Windsor,  (519) 973-7062.  Authors will be notified of acceptance
in February 1993, and final camera ready papers (up to  8  pages)
will be due in March 1993.  Conference proceedings will be avail-
able at the symposium.


   Americas' Chair        European Chair        Pacific/Asian Chair

Prof. Mary Jane Irwin   Dr. Simon Knowles    Prof. Naofumi Takagi
Dept. of CmpSc          Inmos Limited        Dept. of Info. Science
333 Whitmore Lab        1000 Aztec West      Faculty of Engr.
Penn State Univ.        Almondsbury          Kyoto Univ.
Univ. Park, PA 16802    Bristol BS12 4SQ     Kyoto 606-01
USA                     United Kingdom       Japan

Tel: (814) 865-1802     +44-454-616616       +81-75-753-5382
FAX: (814) 865-3176     +44-454-617910       +81-75-753-5379

mji@cs.psu.edu          simonk@inmos.co.uk   takagi@kuis.kyoto-u.ac.jp


Sponsored by the IEEE Computer Society
From: joel@ce.ucsc.edu
Newsgroups: comp.lsi
Subject: Large IO Packages
Date: 17 Aug 1992 17:21:23 GMT
Organization: Computer Engineering, UC Santa Cruz
Distribution: usa
NNTP-Posting-Host: arapaho.ucsc.edu
Originator: joel@arapaho


I am designing a project that has some unique packaging
requirements.   The device I am designing is a multichip
module with exterior dimensions about 20cm by 40cm and
between 400 and 600 IO.  I am currently considering
ceramic packages - either ceramic pin grid arrays or
ceramic land grid arrays.  I have been in contact with
one vendor (NTK) of these parts, but they have no standard packages
in this range, so it is necessary to pay a large amount for
NRE.  I am wondering what other vendors sell large IO packages
and what other universities have done to solve this problem.

Joel Darnauer (joel@ce.ucsc.edu)

Xref: sparky comp.lsi:542 comp.lsi.cad:879
From: tk@ai.mit.edu (Tom Knight)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Re: Multiported Register Files
Date: 18 Aug 92 01:33:22 GMT
Followup-To: comp.lsi
Organization: MIT Artificial Intelligence Lab
In-reply-to: andrea@esp.ics.uci.edu's message of 14 Aug 92 20:17:06 GMT

In article <2A8C14C1.24975@ics.uci.edu> andrea@esp.ics.uci.edu (Andrea Capitanio) writes:

   From: andrea@esp.ics.uci.edu (Andrea Capitanio)
   Summary: Do anybody knows anything about multiported SRAMs with more than 6 ports ?

   I'm wondering if anybody out there is aware of any implementation
   of multi-port static memories with large (i.e., >= 6) # of ports
   or if any reference to the topic exist.

There are a few ideas that are "well known" that should be mentioned.
One is that you can duplicate the register file any number of times to
make multiple read ports.  The real problem is multiple write ports.
A nice arrangement is to share write bit lines across a pair of
arrays, and split read bit lines between the two arrays.  Then every
write is seen by both arrays, and there are independent read ports on
each side of the pair of arrays.

IBM used single ended reads and writes in the RT processor.  If you
know that you will do both a read and a write in a single cycle, then
shared bit lines aren't a plus.  You can specialize the bit line
wiring to distinguish read and write bit lines -- the read lines can
get driven by large devices, and the feedback inverter, which must be
overpowered by the write data, can be made small. This was in
in the technical paper collection IBM published on the RT in about
1987.  I'm not sure if it ever made it into a journal.  "Romp/MMU
Circuit Technology and Chip Design" R.A. DuPont, et al., p. 86, in IBM
RT Personal Computer Technology, Form SA23-1057, IBM Engineering
Systems Products, 472 Wheelers Farms Rd., Milford, CT 06460.

You might be amused (but probably only amused) by the paper of Rivest
and Glasser "A Fast Multiport Memory Based on Single Port Memory
Cells" in which they propose bulding multiport rams which handle
addressing conflicts by intentionally introducing errors into the
array, but only in single bit positions, such that the errors can be
later corrected on a read operation.  MIT Lab for Computer Science
memo TM-455 July 1991.
From: krste@ICSI.Berkeley.EDU (Krste Asanovic)
Newsgroups: comp.lsi
Subject: Die aspect ratio.
Date: 13 Aug 1992 23:34:55 GMT
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Distribution: world
NNTP-Posting-Host: icsib43.icsi.berkeley.edu

I've a few questions for the VLSI hackers out in industry.

Sun in particular with the Viking, the cache controller, and the
SPARC90, have produced many exactly square die recently. Also, there
were quite a few other chips at this year's Hot Chips that were
exactly square (or at least to the nearest 0.1mm).

It seems unlikely that an irregular design such as a processor or
cache controller would map naturally to a square die floorplan.  Is
there some inherent yield or manufacturability advantage to having a
square die?  I can think of reticle size and maybe efficient wafer
tiling as two reasons.

Rectangular die give more perimeter per unit area if a design is pad
limited. What's the largest sensible/known aspect ratio? (We've done
one processor die with an aspect ratio of 2.3:1).

Thanks.

-- 
Krste Asanovic,                 Computer Science Division, 
email: krste@cs.berkeley.edu    571 Evans Hall
phone: +1 (510) 643-8733        University of California at Berkeley
fax:   +1 (510) 643-7684        CA 94720, USA
Xref: sparky comp.lsi:544 comp.lsi.cad:881