Messages from 3000

Article: 3000
Subject: PDW'96 Advance Program
From: robins@.cs.Virginia.EDU (Gabriel Robins)
Date: Mon, 11 Mar 1996 20:14:58 GMT
Links: << >> << T >> << A >>


Dear Colleagues,

   Enclosed below is the advance program for the 1996 ACM/SIGDA
Physical Design Workshop, which is co-sponsored the U.S. National
Science Foundation.

   This year's workshop will emphasize deep-submicron and
high-performance issues, and will also feature a special track on
micro electromechanical systems (MEMS), chaired by Ken Gabriel of ARPA.

For more information, please see our WWW home page at:

   http://www.cs.virginia.edu/~pdw96/

Please pass along this advance program to your collagues.

Thanks,

Gabe

p.s.  Please note that the the hotel room reservation deadline is
      March 24.  In order to promote free-flowing discussion among the
      participants, attendance in this workshop will be limited, so we
      encourage you to register soon.

======================================================
Name:           Prof. Gabriel Robins
                General Chair, PDW'96
U.S. Mail:      Department of Computer Science
                Thornton Hall
                University of Virginia
                Charlottesville, VA 22903-2442
Phone:          (804) 982-2207
FAX:            (804) 982-2214
E-mail:         robins@cs.virginia.edu
WWW:            http://www.cs.virginia.edu/~robins/
======================================================

=============================================================================

                           ADVANCE PROGRAM

               Fifth ACM/SIGDA Physical Design Workshop
 April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA

                  http://www.cs.virginia.edu/~pdw96/


The ACM/SIGDA Physical Design Workshop (PDW'96) provides a relaxed
atmosphere for exchange of ideas and promotes research in critical
subareas of physical design for VLSI systems.

This year's workshop emphasizes deep-submicron and high-performance
issues, and also provides a special focus on opportunities in CAD for
micro electromechanical systems (MEMS).  There are four outstanding
panel sessions:

 (1) future needs and directions for deep-submicron physical design,

 (2) physical design needs for MEMS,

 (3) manufacturing and yield issues in physical design, and 

 (4) critical disconnects in design views, data modeling, and back-end
     flows (e.g., for physical verification).

There are also many outstanding technical paper sessions.
Free-flowing discussion will be promoted through the limited workshop
attendance, the poster session and the "open commentary" mechanism in
each technical session, as well as a concluding open problems session.
During the workshop, a benchmarks competition will occur in the areas
of netlist partitioning and performance-driven cell placement.

=============================================================================
                           SUNDAY, APRIL 14
=============================================================================

6:00pm-8:30pm: Registration
  (the registration desk will also be open 8:00am-5:00pm on Monday
   and 8:00am-12:00pm on Tuesday)

7:00pm-8:30pm: Reception (refreshments provided)

=============================================================================
                           MONDAY, APRIL 15
=============================================================================

8:30am-8:40am: Welcome

8:40am-10:00am: Session 1, Timing-Driven Interconnect Resynthesis

  Interconnect Layout Optimization by Simultaneous Steiner Tree
  Construction and Buffer Insertion, T. Okamoto and J. Cong (UC Los Angeles)

  Simultaneous Routing and Buffer Insertion for High Performance
  Interconnect, J. Lillis, C.-K. Cheng and T.-T. Lin (UC San Diego)

  Timing Optimization by Redundancy Addition/Removal, L. Entrena, E. Olias
  and J. Uceda (U. Carlos III of Madrid and U. Politecnica of Madrid) 

  Open Commentary - Moderators: D. Hill (Synopsys),
                                P. Suaris (Interconnectix)

10:00am-10:20am: Break

10:20am-12:00pm: Session 2, Interconnect Optimization

  Optimal Wire-Sizing Formula Under Elmore Delay Model, 
  C. P. Chen, Y. P. Chen and D. F. Wong (U. Texas Austin)

  Reducing Coupled Noise During Routing, A. Vittal and M. Marek-Sadowska 
  (UC Santa Barbara) 

  Simultaneous Transistor and Interconnect Sizing Using General
  Dominance Property, J. Cong and L. He (UC Los Angeles)

  Hierarchical Clock-Network Optimization, D. Lehther, S. Pullela, 
  D. Blaauw and S. Ganguly (Somerset Design Center and Motorola) 

  Open Commentary - Moderators: D. Hill (Synopsys),
                                M. Lorenzetti (Mentor)

12:00pm-2:00pm: Lunch

  Workshop Keynote Address: Prof. C. L. Liu, U. of Illinois
  Algorithmic Aspects of Physical Design of VLSI Circuits

2:00pm-2:45pm: Session 3, A Tutorial Overview of MEMS

  Speaker: K. Gabriel (ARPA)

2:45pm-3:00pm: Break

3:00pm-4:15pm: Session 4, Physical Design for MEMS

  Physical Design for Surface Micromachined MEMS, Gary K. Fedder and
  Tamal Mukherjee (Carnegie-Mellon U.)

  Physical Design Support for MCNC/MUMPS, R. Mahadevan (MCNC)

  Synthesis and Extraction for MEMS Design, E. Berg, N. Lo and 
  K. Pister (UC Los Angeles)

4:15pm-4:30pm: Break

4:30pm-6:00pm: Session 5, Panel: Physical Design Needs for MEMS

  Moderator: K. Pister (UC Los Angeles)

  Panelists include:
    S. Bart (Analog Devices)
    G. Fedder (Carnegie-Mellon U.)
    K. Gabriel (ARPA)
    I. Getreu (Analogy)
    R. Grafton (NSF)
    R. Mahadevan (MCNC)
    J. Tanner (Tanner Research)

6:00pm-8:00pm: Dinner

8:00pm-9:30pm: Session 6, Panel: Deep-Submicron Physical Design:
                          Future Needs and Directions

  Panelists include:
    T. C. Lee (former VP Eng, SVR;  President/CEO, Neo Paradigm Labs)
    L. Scheffer (Architect, Cadence) 
    W. Vercruysse (UltraSPARC III CAD Manager, Sun) 
    M. Wiesel  (CAD Manager, Intel) 
    T. Yin (VP R&D, Avant!) 

=============================================================================
                          TUESDAY, APRIL 16
=============================================================================

8:30am-9:50am: Session 7, Partitioning



  VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement 
  Techniques, S. Dutt and W. Y. Deng (U. Minnesota and LSI Logic)

  A Hybrid Multilevel/Genetic Approach for Circuit Partitioning,
  C. J. Alpert, L. Hagen and A. B. Kahng (UC Los Angeles and Cadence)

  Min-Cut Replication for Delay Reduction, J. Hwang and A. El Gamal
  (Xilinx and Stanford U.)

  Open Commentary - Moderators: J. Frankle (Xilinx),
                                L. Scheffer (Cadence)

9:30am-10:10am: Break

10:10am-11:50am: Session 8, Topics in Hierarchical Design

  Two-Dimensional Datapath Regularity Extraction, R. Nijssen and 
  J. Jess (TU Eindhoven)

  Hierarchical Net Length Estimation, G. Zimmermann (U. Kaiserslautern)

  Exploring the Design Space for Building-Block Placements Considering
  Area, Aspect Ratio, Path Delay and Routing Congestion,  H. Esbensen and 
  E. S. Kuh (UC Berkeley)

  Genetic Simulated Annealing and Application to Non-Slicing Floorplan
  Design, S. Koakutsu, M. Kang and W. W.-M. Dai (Chiba U. and UC Santa Cruz) 

  Open Commentary

11:50pm-1:30pm: Lunch


1:30pm-3:00pm: Session 9, Poster Session

  Physical Layout for Three-Dimensional FPGAs, M. J. Alexander, J. P.
  Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins (U. of Virginia)

  Efficient Area Minimization for Dynamic CMOS Circuits, B. Basaran
  and R. Rutenbar (Carnegie-Mellon U.)

  A Fast Technique for Timing-Driven Placement Re-engineering,
  M. Hossain, B. Thumma and S. Ashtaputre (Compass Design Automation)

  An Approach to Layout and Process Verification for Microsystem,
  Physical Design, K. Hahn and R. Bruck (U. Dortmund) 

  Computer  Aided Micro-Machining for Wet Etch Fabrication,
  M. K. Long, J. W. Burdick and T. J. Hubbard (Caltech)

  Over-the-Cell Routing with Vertical Floating Pins, I. Peters, P. Molitor
  and M. Weber (U. Halle and Deuretzbacher Research GmbH)

  Congestion- Balanced Placement for FPGAs, R. Sun, R. Gupta and C. L. Liu 
  (Altera and U. Illinois)

  Fanout Problems in FPGA, K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu
  (UC Santa Barbara and Actel)

  An Optimal Pairing and Chaining Algorithm for Layout Generation,
  J. Velasco, X. Marin, R. P. Llopis and J. Carrabina (IMB-CNM
  U. Autonoma de Barcelona, Philips Research Labs Eindhoven)

  Clock-Delayed Domino in Adder and Random Logic Design, G. Yee and 
  C. Sechen (U. Washington)


3:00pm-4:00pm: Session 10, Manufacturing/Yield Issues I

  Layout Design for Yield and Reliability, K. P. Wang, M. Marek-Sadowska 
  and W. Maly (UC Santa Barbara and Carnegie-Mellon U.)

  Yield Optimization in Physical Design, V. Chiluvuri (Motorola) 
  (invited survey paper)

4:00pm-4:15pm: Break

4:15pm-5:45pm: Session 11, Panel: Manufacturing/Yield Issues II

  Panelists include:
    V. Chiluvuri (Motorola)
    I. Koren (U. Massachusetts Amherst)
    J. Burns (IBM Watson Research Center)
    W. Maly (Carnegie-Mellon U.)

5:45pm-7:30pm: Dinner

7:30pm-9:30pm: Session 12, Panel: Design Views, Data Modeling and
                           Flows: Critical Disconnects
  A Talk by C. Sechen (U. Washington)

  A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph
  and Tile Expansion Approach, H.-P. Tseng and C. Sechen (U. Washington)

  A Multi-Layer Chip-Level Global Route, L.-C. E. Liu and C. Sechen
  (U. Washington)

  Panelists include:
    W. W.-M. Dai (UC Santa Cruz, VP Ultima Interconnect Technologies)
    L. Jones (Motorola)
    D. Lapotin (IBM Austin Research Center)
    E. Nequist (VP R&D, Cooper & Chyan)
    R. Rohrer (Chief Scientist, Avant!)
    P. Sandborn (VP, Savantage)

=============================================================================
                         WEDNESDAY, APRIL 17
=============================================================================

8:30am-9:50am: Session 13, Performance-Driven Design

  A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven
  Placement Problems, G. Tellez, D. A. Knol and M. Sarrafzadeh 
  (Northwestern U.)

  Reduced Sensitivity  of Clock Skew Scheduling to Technology Variations,
  J. L. Neves and E. G. Friedman (U. Rochester) 

  Multi-Layer Pin Assignment for Macro Cell Circuits, L.-C. E. Liu and
  C. Sechen (U. Washington)

  Open Commentary

9:50pm-10:10pm: Break

10:10am-11:30am: Session 14, Topics in Layout

  Constraint Relaxation in Graph-Based Compaction, S. K. Dong, P. Pan,
  C. Y. Lo and C. L. Liu (Silicon Graphics, Clarkson U., Lucent, U. Illinois)

  An O(n) Algorithm for Transistor Stacking with Performance Constraints,
  B. Basaran and R. Rutenbar (Carnegie-Mellon U.)

  Efficient Standard Cell Generation When Diffusion Strapping is Required,
  B. Guan and C. Sechen (Silicon Graphics and U. Washington)

  Open Commentary - Moderator: A. Domic (Cadence)

11:30am-12:00pm: Session 15, Open Problems

  Moderators: A. B. Kahng (UC Los Angeles), B. Preas (Xerox PARC)

12:00pm-2:00pm: Lunch (and benchmark competition results)

2:00pm: Workshop adjourns

=============================================================================
                       TRAVEL AND ACCOMODATIONS
=============================================================================

PDW '96 is being held at the Sheraton Reston in Reston, Virginia, near
Washington, D.C.  The hotel is minutes from Dulles International
Airport (IAD), and 24-hour courtesy shuttles are available from the
airport to the hotel.  The area is also served by Washington National
Airport (DCA), about 20 miles away, and Baltimore-Washington
International Airport (BWI), about 50 miles away.

The Sheraton Reston is located at:
  11810 Sunrise Valley Drive
  Reston, Virginia 22091
  phone: 703-620-9000
  fax: 703-860-1594
  reservations: 800-392-ROOM

*** Please make your room reservation directly with the Reston ***
*** Sheraton hotel.                                            ***

Driving directions from Dulles Airport: take the Washington Dulles
Access and Toll Road (route 267) to the Reston Parkway Exit (3).  Turn
right at the light after paying toll.  Take the next left onto Sunrise
Valley Drive, and continue for a couple blocks to the Sheraton (on
your left).

A block of rooms is being held for the nights of Sunday through
Wednesday (April 14 through April 17). Room rates are $95 per night
for single occupancy, and $105 per night for double occupancy. The
number of rooms available at these rates is limited, and they are only
being held through March 24 (so early registration is highly recommended).

The Washington D.C. weather tends to be chilly in April, so warm dress
is suggested for the outdoors.

=============================================================================
                     SIGHTSEEING AND ATTRACTIONS
=============================================================================

The Nation's Capitol offers much in the way of sightseeing.  The most
popular destinations are located in downtown Washington D.C.,
surrounding several square miles of park area known as the "National
Mall."  There is no charge to visit the National Memorials located on
the Mall, which include the Washington Monument, where you may ascend
555 feet to an observation post; the Lincoln Memorial, whose design
adorns the back of the US penny; the Jefferson Memorial, which
includes a 19-foot bronze statue of Thomas Jefferson; and the Vietnam
Memorial, a long wall of black Indian granite dedicated in 1982.

The Smithsonian Institution (telephone (202) 357-2700) operates a
number of superb museums that flank the National Mall, including:

  Freer Gallery of Art (Asian and 19th and 20th-century American art)
  Hirshhorn Museum and Sculpture Garden (modern and contemporary art)
  National Air and Space Museum (history of aviation and space exploration)
  National Museum of African Art (collection and study of African art)
  National Museum of American Art (paintings, graphics, and photography)
  National Museum of American History (technology and culture in America)
  National Museum of Natural History (history of the natural world)
  National Portrait Gallery (portraits of distinguished americans)
  National Postal Museum (history of postal communication and philately)
  Sackler Gallery of Asian art (from ancient to present)

Other attractions and tours around the D.C. area include (please call
the numbers below for schedules):

  Arlington National Cemetary (703) 697-2131
  Bureau of Engraving and Printing (202) 622-2000
  Congressional buildings (202) 225-6827
  FBI Headquarters (202) 324-3447
  Library of Congress (202) 707-5000
  National Aquarium (202) 482-2825
  National Archives (202) 501-5000
  National Zoological Park (202) 673-4821
  The Pentagon (703) 695-1776
  Supreme Court (202) 479-3030
  Treasury Department (202) 622-2000
  The White House (202) 456-7041

There are a number of reasonably priced eating places on the Mall; the
East Wing of National Gallery and the Air and Space Museums offer good
food and a place to sit down after sightseeing.  Provisions will be
made for low-cost transportation to and from the Mall and downtown
Washington D.C., so bring your camera and strolling shoes and enjoy
our Nation's Capital!

=============================================================================
WORKSHOP ORGANIZATION
=============================================================================

General Chair: 

  G. Robins (U. of Virginia)

Technical Program Committee:

  C. K. Cheng (UC San Diego)
  J. P. Cohoon (U. of Virginia)
  J. Cong (UC Los Angeles)
  A. Domic (Cadence)
  J. Frankle (Xilinx)
  E. Friedman (Rochester)
  D. Hill (Synopsys)
  L. Jones (Motorola)
  A. B. Kahng (UC Los Angeles, Chair)
  Y.-L. Lin (Tsing Hua)
  K. Pister (UC Los Angeles)
  M. Marek-Sadowska (UC Santa Barbara)
  C. Sechen (Washington)
  R.-S. Tsay (Avant!)
  G. Zimmermann (Kaiserslautern)

Steering Committee:

  M. Lorenzetti (Mentor Graphics)
  B. Preas (Xerox PARC)

Keynote Address:

  C. L. Liu (Illinois)

Benchmarks Co-Chairs:

  F. Brglez (NCSU)
  W. Swartz (TimberWolf Systems)

Local Arrangements Chair:

  M. J. Alexander (U. of Virginia)

Treasurer:

  S. B. Souvannavong (HIMA)

Publicity Chair:

  J. L. Ganley (Cadence)

Sponsors:

  ACM / SIGDA
  U.S. National Science Foundation
  Avant! Corporation

=============================================================================
                        WORKSHOP REGISTRATION
=============================================================================

               Fifth ACM/SIGDA Physical Design Workshop
 April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA

Name: _______________________________________________________________

Company/University: _________________________________________________

Title: ______________________________________________________________

Address: ____________________________________________________________

City: _________________________________________ State: ______________

Phone: ____________________________ Email: __________________________


                Registration Fees (Includes All Meals)

              Advance (Through April 1)  Late (After April 1/On-Site)
ACM Members         __ $355                      __ $440
Non-ACM             __ $455                      __ $540
Students            __ $250                      __ $250

         ACM Membership Number: _____________________________

         Dietary restrictions, if any: ______________________

         Special needs: _____________________________________

The registration fee includes the workshop proceedings and all meals
(i.e., 3 breakfasts, 3 lunches, and 2 dinners), refreshments during
breaks, and a reception on Sunday evening.  The total number of
attendees is limited (registrations will be returned if the workshop
is oversubscribed).

*** Note: Hotel reservations must be made directly with the Sheraton ***
*** (see above).                                                     ***

The only acceptable forms of payment are checks (personal, company,
and certified/bank checks) in US funds drawn on a US bank and made
payable to "Physical Design Workshop 1996" (credit cards will not be
accepted).  Payment must accompany your registration. No FAX or Email
registrations will be processed.

Please mail your payment (checks only) along with this registration form to:

  Sally Souvannavong, Treasurer
  1996 ACM/SIGDA Physical Design Workshop
  Department of Computer Science
  Thornton Hall
  University of Virginia
  Charlottesville, VA 22903-2442 USA

  Phone: (804) 982-2200
  Email: pdw96@cs.virginia.edu

Cancellations must be in writing and must be received by March 31, 1996.

=============================================================================
The Latex and postscript versions of this advanced program may be
obtained from http://www.cs.virginia.edu/~pdw96/
=============================================================================

Article: 3001
Subject: Re: Reconfigurable Computing Languages
From: Brad Taylor <blt@emf.net>
Date: Mon, 11 Mar 1996 21:42:23 -0800
Links: << >> << T >> << A >>

Herman Schmit wrote:

> Abandon all hope of porting compute-intensive code to reconfigurable
> machines.  I've looked at a lot of integer-oriented, compute-intensive
> algorithms, and although you can often get whiz-bang speed-ups using
> FPGAs, you can't do it from the C code written for a CPU.  The more
> compute-critical something is, the more people pound on it, and the
> more machine-specific the code gets.

....
> 
> I think the only reason to champion C or some variant is that people
> are not very familiar with VHDL or Verilog, and they make the
> assumption (as you did, Steve) that they cannot easily specify
> algorithms in these languages. 

To run old code on an FPGA:
(1) Build a CPU in the FPGA 
(2) Compile the C code.

It may be that it doesn't run faster, but a good compiler (which is 
aware the target hardware is an FPGA) at least has a chance of 
optimizing the code for speed.   Better compilers, and better 
hardware, will allow the code to run faster and faster.  

I disagree with your statement that poeple who want to write in C, 
simply aren't able to write in an HDL. I believe there are valid 
reasons to avoid HDLs.

Tell me if I'm wrong, but I don't believe any "HDL" compiler can speed 
up an "algorithm" by removing clocks.  What do you have when the VHDL 
design is done?  A dead design which can only be implemented exactly 
as is, and can only be understood by simulation, by a select group
of hardware programmers. Of course, the combinatorials can be 
optimised, registers retimed, and the code can be implemented
in faster silicon, but that's all I can think of in the way of 
optimization.

When you write in the concurrent domain, you take all responsibility
for timing, synchronization, pipelining, partitioning, communication
 ...  (I could go on)

For myself, if I assume virtual memory, use floating point, and write 
in C without regard to speed, I can write code orders of magnitude 
faster than when I implement the same algorithm in an HDL. And someone 
else might actually be able to understand it.  The self documenting
nature of single threaded C is it's greatest asset.  I don't want to
throw all this away just to get speed.  I don't believe I have to. 
This is why  I keep pushing ANSI C as an HDL, and pushing for hardware 
aware C compilers.  

By the way,  There are a few really bad things you can do in C that 
make it impossible to convert time into space (parallelizing it). 
These can be avoided in new code. Interestingly, many of these are 
considered bad form by the software community.  Here is a short list:

- recursive function calls with parameters
- exit, break and continue statements
- self modifying code
- writable jump tables
- variable loop limits
- global data 
- reuse of variables
...

I'm not a great fan of C's syntax, but there really is no good syntax
for this stuff.  I know bit fields are obnoxious in C and so on, but 
the fact remains that it is a workable language, which has been adopted
as the language of the software community. 

Thanks for the opportunity to express my opinions.  

Brad Taylor

/=============================<>=====================================\
|            Brad Taylor                                 blt@emf.net |
\=============================<>=====================================/

Article: 3002
Subject: Re: DIY Bitblaster ?
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 12 Mar 1996 09:04:39 GMT
Links: << >> << T >> << A >>

In article <499670.32541.3919@kcbbs.gen.nz> moby@kcbbs.gen.nz (Mike Diack) writes:
>Anyone out there figured out how to make one of these little boxes that
>interface between an RS232 port and the serial input and control ports
>of the Altera 8000 series FPGAs ?.
>cheers
>Mike

The Altera FLEX 8000 parts load data almost identically to the Xilinx 
FPGAs. If the Altera part is put into Pasive Serial mode (equivalent to 
the Xilinx Serial Slave mode) then configuration is a matter of putting
the device into program mode (yank on the PROGRAM pin), then supply data
on the DATA0 pin while clocking it in on the DCLK pin. Watch the 
Conf_Done pin to see when you are done.

This is most easilly done with a parallel port of a PC rather than the 
RS232 port, which would require significant logic (compared to the 
parallel port) to be usable for down load.

My downloader (on a PC parallel port) uses just one 74C125 (need to be 
able to deal with the bi-directional Program/Done pin on Xilinx 3K chips).

A simple buffer is all thats needed for Xilinx 4000 or Altera FLEX parts.
Since this does not require much power, a common trick is to power the 
buffer from the parallel port (which does not have a power out signal), 
by tying the power pin of the buffer to data bit 7 of the parallel port, 
and remembering to write a '1' to that bit before you do anything else 
with the buffer. (A cap, and a short wait is also worthwhile, after 
setting the bit high :-)  )

All the sequencing of the program signal, data bits and DCLK, and checking
for CONF_DONE are all done under software. Bring the CONF_DONE signal 
back into the printer port on a line like 'paper-out' or 'ACK'

All the best

	Philip Freidin.

Article: 3003
Subject: Xact6.o too slow
From: Pierre Cluzel <cluzel@ipnl.in2p3.fr>
Date: Tue, 12 Mar 1996 11:09:57 +0100
Links: << >> << T >> << A >>

I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
years) and my first work has been to test the software with the tutorial
example CALC.1.
	I have never experienced crashes during schematic editing but the
implementation software is very VERY SLOW . My machine configuration is
: Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
Version 3.1.
	PPR running with DOS (xdm) takes about 2-3 min. to implement the
tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
the same job in the Windows version...!!
Is my machine badly configured or Xactstep is really too slow ?
Could some people do the same test and reply me the result for
comparision and eventually modify my configuration files.

Pierre CLUZEL
Institut de Physique Nucleaire de Lyon
43 boulevard du 11 Novembre
F 69622 VILLEURBANNE CEDEX
Phone : (33) 7244 8420
Fax : (33) 7244 8004
Email : cluzel@ipnl.in2p3.fr

Article: 3004
Subject: Re: Xact6.o too slow
From: ecla@world.std.com (alain arnaud)
Date: Tue, 12 Mar 1996 16:15:56 GMT
Links: << >> << T >> << A >>

Pierre Cluzel (cluzel@ipnl.in2p3.fr) wrote:
: I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
: years) and my first work has been to test the software with the tutorial
: example CALC.1.
: 	I have never experienced crashes during schematic editing but the
: implementation software is very VERY SLOW . My machine configuration is
: : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
: Version 3.1.
: 	PPR running with DOS (xdm) takes about 2-3 min. to implement the
: tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
: the same job in the Windows version...!!
: Is my machine badly configured or Xactstep is really too slow ?
: Could some people do the same test and reply me the result for
: comparision and eventually modify my configuration files.

	The max difference in performance between running under dos or
	or window should be between 10-15%. that is xact5.2 under dos will
	be that much faster on average than xact 6.0 under windows.

	this seems that the problem is probably due to either low
	conventional memory or a small swap space. Initial beta versions
	of XACT 6.0 were 30% slower than xact5.2 but that got fixed before
	the production release.

	--Alain Arnaud

Article: 3005
Subject: Re: Multiple FPGA Partitioning
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Tue, 12 Mar 1996 17:18:50 GMT
Links: << >> << T >> << A >>

Ed,

Altera has software that will do the auto-partitioning for you.
However, here is the big issue:
- delays between chips.

If you have any sort of speed requirement that must be met, you'll
need to hand-partition, and make sure that you have little/no logic on
the paths from one FPGA to the other.  Otherwise, adding in inter-chip
routing delays will greatly reduce your clock frequency.

Also, remember this: when you build a board, your connections between
FPGAs will be fixed.  If you re-partition your design, it may require
you to rev. your board, to add more connections between chips.

I did a 10-FPGA board, and this was our experience.

Hope this helps,
Erik Jessen

Article: 3006
Subject: Re: Reconfigurable Computing Languages
From: herman@galant.ece.cmu.edu (Herman Schmit)
Date: 12 Mar 1996 21:48:25 GMT
Links: << >> << T >> << A >>

Brad Taylor (blt@emf.net) wrote:
: Herman Schmit wrote:

: > I think the only reason to champion C or some variant is that people
: > are not very familiar with VHDL or Verilog, and they make the
: > assumption (as you did, Steve) that they cannot easily specify
: > algorithms in these languages. 

: I disagree with your statement that poeple who want to write in C, 
: simply aren't able to write in an HDL. I believe there are valid 
: reasons to avoid HDLs.

: Tell me if I'm wrong, but I don't believe any "HDL" compiler can speed 
: up an "algorithm" by removing clocks.  What do you have when the VHDL 
: design is done?  A dead design which can only be implemented exactly 
: as is, and can only be understood by simulation, by a select group
: of hardware programmers. Of course, the combinatorials can be 
: optimised, registers retimed, and the code can be implemented
: in faster silicon, but that's all I can think of in the way of 
: optimization.

I think you've illustrated the misconception about HDL's.  It is
trivial to write single-threaded, non-clocked, easy-to-understand
programs in Verilog or VHDL.  These languages have additional
constructs that allow the specifications of everything from clocks to
device netlists, and if you write at such a low level of abstraction,
it is very difficult to recover the original intent of the
application.  Both HDLs have sufficient syntax to describe any
algorithm at the same level as C.  I'll illustrate this with my next
post.

: When you write in the concurrent domain, you take all responsibility
: for timing, synchronization, pipelining, partitioning, communication
:  ...  (I could go on)

Just because the language supports them doesn't mean that you HAVE to
use concurrent processes.  

Herman

------------------------------------------------
Herman Schmit, Research Engineer
Department of Electical and Computer Engineering
Carnegie Mellon University
5000 Forbes Ave., Pittsburgh PA 15213
Tel: (412) 268-6642
email: herman@ece.cmu.edu

Article: 3007
Subject: Re: Multiple FPGA Partitioning
From: Ken Wood <ken@eda.com.au>
Date: Wed, 13 Mar 1996 21:41:19 +1000
Links: << >> << T >> << A >>

Erik Jessen wrote:
> 
> Altera has software that will do the auto-partitioning for you.
> However, here is the big issue:
> - delays between chips.
> 
> If you have any sort of speed requirement that must be met, you'll
> need to hand-partition, and make sure that you have little/no logic on
> the paths from one FPGA to the other.  Otherwise, adding in inter-chip
> routing delays will greatly reduce your clock frequency.

There is a startup company called Auspy Development selling an FPGA
partitioning tool which they claim to be very powerful.  I haven't tried
it myself, but it is supposed to take inter-chip delays into account
when attempting to meet timing constraints. If the software performs as
advertised, it should do everything you want.

For more information, contact:

  auspy@netcom.com

or phone: +1-408-252 5813.

Cheers,
Ken

-- 
Ken Wood  -  Mentor Technologies / EDA Solutions   email: ken@eda.com.au
Office: Sydney, Australia        Tel: 61-2-413 4600   Fax: 61-2-413 4622
Tech Support: support@eda.com.au        Other Enquiries: info@eda.com.au
Mentor Graphics: http://www.mentorg.com/   MT: ftp://ftp.eda.com.au/pub/

Article: 3008
Subject: Sq. Roots and Languages
From: herman@galant.ece.cmu.edu (Herman Schmit)
Date: 13 Mar 1996 14:00:07 GMT
Links: << >> << T >> << A >>

The April issue of Dr. Dobbs Journal includes a discussion of quickly
computing integer square roots.  I'm posting it here for two reasons.
First, I think its may be good for FPGA implementation.  Second, I
think we need to have some specifics in this argument about the
appropriate languages for reconfigurable computing, and I wanted to
illustrate that Verilog can be as easy to understand, as timing-free,
and as single-threaded as C.  The first listing is in Verilog, the
second in C.  There are no clocks, no timing, and no netlists in the
Verilog.  The only reason I think that C should be used over Verilog
in this particular case is that the Dr. Dobb's article is written in
C.  Assuming the same quality of compiler for C and Verilog, using C
would reduce time to market by roughly 15 minutes (the time it took me
to translate this C fragment to Verilog.)  

I reckon a VHDL description of this algorithm would be slightly more
verbose (isn't the "V" in VHDL for verbose?), but I don't think it
would be significantly more difficult to understand than either C or
Verilog. 

Herman


VERILOG:
-----------------------------------------------------------------------------
module main;

   function [15:0] sqroot;
      input [31:0] N;
      
      reg [31:0] l2, t, u, v, u2, n;

      if (2 > N)
       sqroot = N[15:0];
      else
       begin
	  l2 = 0;
	  t = N;
	  t = t >> 2;
	  while(t > 0)
	   begin
	      l2 = l2 + 1;
	      t = t >> 2;
	   end
	  u = 1 << l2;
	  v = u;
	  u2 = u << l2;
	  while (l2>0)
	   begin
	      l2 = l2 - 1;
	      v = v >> 1;
	      n = (u + u + v) << l2;
	      n = n + u2;
	      if (n <= N)
	       begin
		  u = u + v;
		  u2 = n;
	       end
	   end
	  sqroot = u[15:0];
       end
   endfunction

   reg [31:0] i,t;
  
   initial
    begin
       for(i= 4; i<50; i=i+1)
         begin
	    t = sqroot(i);
	    $display("%d\t%d", i, t);
	 end
       $display("%d\t%d\n", 32'hffffffff, sqroot(32'hffffffff));
    end
      
endmodule 
-----------------------------------------------------------------------------


C: 
-----------------------------------------------------------------------------
/****************************************************************************
 *
 *  Filename: binomial.c
 *  Original Author: Peter Heinrich, Dr Dobbs Journal, April 1996.
 *
 *****************************************************************************/

unsigned long sqroot(unsigned long N)
{
  unsigned long l2, t, u, v, u2, n;

  if (2 > N)
    return N;

  t = N;
  l2 = 0;
  while (t >>= 2)
    l2++;

  u = 1L << l2;
  v = u;
  u2 = u << l2;
  while (l2--) {
    v >>= 1;
    n = (u + u + v) << l2;
    n += u2;
    if (n <= N) {
      u += v;
      u2 = n;
    }
  }
  return (u);
}

main() {
  long int i,t;
  
  for (i = 4; i<50; i++) {
    t = sqroot(i);
    printf("%ld\t%ld\n", i, t);
  }
  printf("%lu\t%lu\n", 0xffffffff, sqroot(0xffffffff));
}
-----------------------------------------------------------------------------
 
------------------------------------------------
Herman Schmit, Research Engineer
Department of Electical and Computer Engineering
Carnegie Mellon University
5000 Forbes Ave., Pittsburgh PA 15213
Tel: (412) 268-6642
email: herman@ece.cmu.edu

Article: 3009
Subject: Re: Xact6.o too slow
From: acher@informatik.tu-muenchen.de (Georg Acher)
Date: 13 Mar 1996 15:20:26 GMT
Links: << >> << T >> << A >>


In article <31454D75.41C67EA6@ipnl.in2p3.fr>, Pierre Cluzel <cluzel@ipnl.in2p3.fr> writes:
|> I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
|> years) and my first work has been to test the software with the tutorial
|> example CALC.1.
|> 	I have never experienced crashes during schematic editing but the
|> implementation software is very VERY SLOW . My machine configuration is
|> : Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
|> Version 3.1.
|> 	PPR running with DOS (xdm) takes about 2-3 min. to implement the
|> tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
|> the same job in the Windows version...!!

Maybe you had just bad luck, PPR never does the same routing again (except you
set the seed=... option). If PPR is swapping all the time, your disk cache
(SMARTDRV) is maybe too big, so there's not much memory left for PPR, that can
cause 'trashing'... Then you should set the DOS-box priority to 90-100, if you
really want quick results.

|> Is my machine badly configured or Xactstep is really too slow ?

The new WIR2XNF.EXE is deadly slow, it takes about 5-10 times longer to convert the
files than in V5.1. My harddisk is heavy accessed (sounds like the seek-tests...)
and nothing helps to speed it up, no matter whether I use DOS, WINDOS, even
SMARTDRIVE with 16MB cache didn't help :-( No I use the old WIR2XNF ;-)
That's my general complaint about the XACT-tools: They are too slow. Even on a
Pentium/100 it takes about 30-40 seconds from starting PPR until it starts with
placing. XNFPREP always needs 40s, no matter if it's just a design with one
gate or 4000 gates. The funny colorfull new 'flow manager' is a nice gimmick, but
when I have my makefile, I run it from DOS with xmake, because it's faster...

-- 
	Bye
	Georg Acher
+--------------------------------------------------------------+
|         Georg Acher, acher@informatik.tu-muenchen.de         |
|           "Oh no, not again !" The bowl of petunias          |
+--------------------------------------------------------------+

Article: 3010
Subject: ORCA Fpgas
From: "Aaron T. Smith" <ats@lems.brown.edu>
Date: Wed, 13 Mar 1996 11:18:28 -0500
Links: << >> << T >> << A >>

Does anyone know die size, transistor counts and such for the ATT2XXX
ORCA series parts?  I have already checked the data sheet and the 
ATT microelectronics web site with no luck.  Why you ask?  I need
to know the size of .35 micron tecnology.  Specifically, how big are
the logic blocks or PLC in ORCA parlance.

Thanks
-- 
----------------------------------------------------------------------------
Aaron Smith - ats@lems.brown.edu
Brown University	
Providence, RI 02912	
----------------------------------------------------------------------------

Article: 3011
Subject: Re: Reconfigurable Computing Languages
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 13 Mar 1996 17:17:20 GMT
Links: << >> << T >> << A >>

>>>>> "BT" == Brad Taylor <blt@emf.net> writes:
In article <31450EBF.61A@emf.net> Brad Taylor <blt@emf.net> writes:
    BT> To run old code on an FPGA: (1) Build a CPU in the FPGA (2)
                                        ^^^^^^^^^^^^^^^^^^^^^^^
    BT> Compile the C code.

    BT> It may be that it doesn't run faster, but a good compiler
    BT> (which is aware the target hardware is an FPGA) at least has a
    BT> chance of optimizing the code for speed.  Better compilers,
    BT> and better hardware, will allow the code to run faster and
    BT> faster.

With current technology you would probably be better off in terms of
cost, performance, design time, etc., to just cobble a cheap
microcontroller/DSP/microprocessor with some FPGAs. FPGA-based CPUs
are just not competitive with their fixed-funtion counterparts for
code written for CPUs.

    BT> Tell me if I'm wrong, but I don't believe any "HDL" compiler
    BT> can speed up an "algorithm" by removing clocks.  What do you
    BT> have when the VHDL design is done?  A dead design which can
    BT> only be implemented exactly as is, and can only be understood
    BT> by simulation, by a select group of hardware programmers. Of
    BT> course, the combinatorials can be optimised, registers
    BT> retimed, and the code can be implemented in faster silicon,
    BT> but that's all I can think of in the way of optimization.

Is there a C compiler that can automatically do all of these things?

Anyhow, these are *not* really language issues. They are primarily
mapping (synthesis) issues.  The general problem of synthesis is one
of transforming one level of abstraction to another, generally going
from a higher-level abstraction to a lower-level specification.  At
the high level (where the intent of the designer is captured), you
want a language that allows the designer to work at a variety of
different levels of abstraction. That way, the designer can work at a
lower level if they need to carefully optimize the circuit, or work at
a higher level (more behavioral) if the results from the synthesis
tools are sufficient. So, the language determines the kinds of
abstractions that the programmer can use and the synthesis tool
determines how the abstraction gets mapped to an implementation.

That being said, VHDL already allows one to work purely at the
behavioral level, writing programs that have no clocks or any other
implementation-specific details. VHDL also allows designers to work at
lower levels. Designers can design at the RTL level, fully specifying
the clocking scheme and datapath operations. Or, the designer can even
directly write netlists in VHDL. And, the designer can seamlessly mix
all of these levels together in one design, using the constructs that
are most appropriate for each level of the design.  All of these
various levels of abstractions require no special treatment; they work
together seamlessly, and VHDL even provides language constructs
(configuration statements) for easy switching between various
architectures to experiment with different implementations.

Purely behavioral VHDL does not synthesize at the moment but this is a
limitation of the synthesis tools, *not the language*.  However, even
though purely behavioral VHDL code is not generally synthesizable, we
find it very useful for describing simulation models for those parts
of an FPGA system that will not be synthesized (memories,
interconnect, CPUs, etc.).  Behavioral code is much easier to write
and simulates more quickly.  However, for those parts of the system
that will be synthesized (the FPGAs), we currently write at the "clock
level" because of restrictions in the *synthesis tools*, not
restrictions in the language.

The Splash-II system from SRC as an excellent example of how VHDL can
be used in different ways on a configurable-computing platform. Each
Splash-II array board has 17 XC4010s. Each 4010 connects to its own
private memory and then connects to its right and left neighbors in
linear systolic fashion. All of the 4010s are also connected to a
crossbar that allows non-linear systolic interconnect schemes.
The entire structure of Splash-II is completely described as a 
VHDL model. Non-synthesizable parts of Splash-II such as memories
are described in purely behavioral terms. For example, the
VHDL code used to model the memories uses linked lists, hash tables,
etc., and also uses a *file I/O* package that will read in memory
data files and initialize these data structures for simultation. These
behavioral models also include timing information and will check
for read accesses to uninitialized memory locations. These behavioral
models are straightforward and easy to understand.

When developing applications for Splash-II, the programmer develops a
synthesizable VHDL model for each of the 4010s. Again, because of
limitations in the synthesis tool and not the language, these models
tend to be at the RTL level. Now, the great thing about Splash is that
I can simulate the VHDL code for the FPGAs along with all of the other
behavioral stuff (memories, etc.) and can debug my design in its
system context. I can't overemphasize the importance of these
system-level simultations in the early stages of the design. Because
all of these simultation models interact seamlessly, I can ensure that
my FPGA designs will interact correctly with all of the memories,
crossbars and interconnect in the system. Once I am happy with the
simulations, I synthesize all of the FPGA designs and download them.

This approach works very well in practice. If you simulate your design
in the behavioral Splash model, it usually always works fine when you
download (at least the parts that you simulated :-) ). When you
download, it is as if you replaced the VHDL models of the memories,
interconnect, FPGAs, etc., with the actual devices on Splash-II. That,
and it runs about 10,000 times faster than the simulation :-).

I post this as an example that uses VHDL at a variety of abstraction
levels (behavioral, structural, RTL) and does it very well. Many of
the things that people want the HDL-C compiler to do are already being
done in VHDL. While I understand the motivation behind wanting to
use C, it is also important to understand what can be done with
current synthesis tools. Many of the assumptions that are being
posted about VHDL/Verilog are just not true.

    BT> When you write in the concurrent domain, you take all
    BT> responsibility for timing, synchronization, pipelining,
    BT> partitioning, communication ...  (I could go on)

Again, you can write behavioral concurrent code in VHDL. And, with
the behavioral compiler coming out from Synopsys, more and more
of this stuff is getting synthesizable. Synopsys claims that their
new compiler handles loop pipelining for example.

    BT> algorithm in an HDL. And someone else might actually be able
    BT> to understand it.  The self documenting nature of single
    BT> threaded C is it's greatest asset.  I don't want to throw all
    BT> this away just to get speed.  I don't believe I have to.  This
    BT> is why I keep pushing ANSI C as an HDL, and pushing for
    BT> hardware aware C compilers.

VHDL is no more difficult to understand than any other language.  The
students in my class pick it up on their own fairly quickly (about 3-4
weeks). They have problems with the synthesis tool, but as I said
before, that is not a language issue, blah, blah, blah. What I have
found interesting is that when students learn VHDL after already
learning C or Pascal, the VHDL simulation models that they write could
almost be directly translated back into C and Pascal. It is clear that
they are thinking in C or Pascal and then converting it to VHDL.

Now, you ask, since my students are already thinking in C, why not use
C in the first place? Well, the main reason is that we have VHDL
synthesis tools (thanks, Synopsys). However, even if that were not the
case, I am not a big fan of C as a target language for synthesis. We
like being able to describe a system with a variety of abstractions
(like the Splash-II example above) and VHDL was *designed* to do
this. I can write purely behavioral code (which is getting more and
more synthesizable all the time) or I can get "down and dirty" and
specify my hardware at the gate level. And, I don't have to do
anything to get it all to work together because the language was
designed to get all this right to begin with.

Article: 3012
Subject: 8085A using FPGAs....
From: ravindra@hal.COM (Ravindra Divekar)
Date: 13 Mar 1996 09:25:49 -0800
Links: << >> << T >> << A >>

Hi everybody!
 I would like to emulate the Intel 8-bit 8085A using FPGAs.
which FPGA would you recommend ?


thanx ... Ravindra.

Article: 3013
Subject: Re: SYNARIO tool for CPLD and FPGA ?
From: Yves Bernard <elecrnd@CAM.ORG>
Date: Wed, 13 Mar 1996 10:41:36 -0800
Links: << >> << T >> << A >>

Sebastien SALAS wrote:
> =

> I am newbie to the FPGA world and a friend of mine asks me that SYNARIO
> from DATA I/O was better than the other tools.
> =

> One of the big advantage is to choose the family
> at the end of the design (ALTERA or XILINX).
> =

> I would like to know if somebody have use SYNARIO tool ?
> I am interested in any information.
> =

> Regards
> =

>                                Sebastien SALAS
> ________________________________________________________________________>=
                   ___                AIME - Campus INSA -
>       /\ |  |\  /|                   Complexe Scientifique de Rangueil
>  ____/__\|__|_\/_|________           31077 TOULOUSE CEDEX
>     /    |  |    |
>    /     |\ |    |          Tel. +33 61 55 98 85   Fax. +33 61 55 98 70
>   /      | \|    |____      E-mail: sebas@aime.insa-tlse.fr
> ________________________________________________________________________
Salut S=E9bastien,

En ce moment, je suis en train d'=E9valuer ce produit pour des applications=
 =

avec PLD de la compagnie ATMEL comme la famille 750 et 1500.

J'ai effectu=E9 des tests pour voir si le m=EAme projet con=E7u graphiqueme=
nt =

(Senario) ou par des =E9quations (ABEL-HDL) aurait les m=EAmes r=E9sultats.=


Les r=E9sultats furent tels que la m=E9thode graphique a p=E9nalis=E9 3 pin=
 =

supl=E9mentaires du PLD 750 pour r=E9-injecter des r=E9sultats interm=E9dia=
res de =

la compilation dans la matrice logique. Il semblerait que la m=E9thode =

graphique laisse =E0 d=E9sirer pour les petits PLD mais devient plus pratiq=
ue =

pour les FPGA.

La m=E9thode par =E9quation s'est av=E9r=E9 beaucoup plus efficace pour les=
 =

petits PLD car je n'ai perdu aucune pin de mon PLD.

Puisque tu as parl=E9 de FPGA, je crois que tous ceci ne te sera pas bien =

utile!?

N=E9anmoins, il y a une chose qui m'a beaucoup choqu=E9 du produit: La =

librairie de gates ne comprenait pas d'inverseur tri-state ou de "CMOS =

transmission GATE" aussi appel=E9 "complementary pair"

Article: 3014
Subject: INDUSTRY GADFLY: "From Beirut To Bosnia" + Reader Response
From: jcooley@world.std.com (John Cooley)
Date: Wed, 13 Mar 1996 21:05:47 GMT
Links: << >> << T >> << A >>


      !!!     "It's not a BUG,                        jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                              (508) 429-4357
    (  >  )
     \ - /      INDUSTRY GADFLY: "From Beirut To Bosnia" & Response
     _] [_          
                      by John Cooley, EE Times Columnist

        Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222

   More than once I've thought of the Verilog/VHDL Wars as being the EDA
industry's equivalent of Beirut.  What has made this war particularly
interesting to watch was the proxy propaganda war being fought via industry
analysts.  Ron Collett of Collett International made big news for predicting
that VHDL was going to beat Verilog some time around '92.  Gary Smith of
Dataquest also caused a minor uproar when he claimed at the '94 DAC that VHDL
revenues were just then beating Verilog revenues and projected it would only
get better for VHDL.  Bill Fuchs, the never shy Chairman of Open Verilog
International (OVI), howled over the past four years that OVI's surveys
found that Verilog's revenues were easily *twice* to *four times* what these
analysts were seeing.  Of course, just like Middle Eastern politics, each
side very quickly refuted the other side's industry numbers while quietly
accusing the other of being secretly affiliated with various VHDL or Verilog
terrorist organizations.

   Suddenly, like UN Peacekeepers coming to Beirut on very large aircraft
carriers floating in the Mediterranean Sea, the industry association of
Electronic Design Automation Companies (EDAC) commissioned their own EDA
wide survey using the good offices of the Big Eight accounting firm Arthur
Anderson.  The bombshell that came out of this study was that although for
the 1994 fiscal year EDAC found a revenue split of 54 per cent for Verilog
to 46 percent for VHDL on a total of $124 million -- for the first three
quarters (forth quarter numbers aren't out yet) of the 1995 fiscal year this
split has <BEGIN ITALICS> changed to 66 per cent for Verilog to 34 per cent
for VHDL <END ITALICS> on a total of $78 million!  Doing his best CEO-speak,
Harvard MBA Alain Hanover (President & CEO of Viewlogic and Chairman of EDAC)
commented: "We needed objective statistics on topics like Verilog versus
VHDL, synthesis, and schematic capture to enable EDA companies to make
intelligent strategic business decisions.  In 1995, we are also seeing a
clear lead in HDLs as the dominate input for design and Verilog as the
predominate language."  (To get a copy of the EDAC Market Statistics report
covering this and much more call (408) 287-6371.)

   A quick phone call to tell Bill Fuchs the news not only yielded a "Yeehaw!"
but also a litany of how frustrating it was for four years to be banging
heads with Dataquest and Collett International when his numbers so wildy
disagreed with theirs.  "Now with EDAC's Arthur Anderson report, my numbers
are being vindicated.  Verilog's won!  I'm quite pleased!"

   Privately I know this issue won't be completely resolved so quickly and
quietly.  Like Beirut, it's a religious war.  (I'm humorously wondering what
the VHDL Fundamentalists will do to undermine this heretical EDAC report.)

   For 1996 I see the EDA industry's crisis-du-jour moving out of the Verilog
vs. VHDL Beirut and into a UNIX workstation vs. PC Bosnia.  Just because EDA
products can run on PC's doesn't mean they can be PC priced.  The economics
don't work.  Yet engineers are genetically predisposed to "gak" at the idea
buying $70,000 worth of software to run on $1,500 worth of PC.  To get a
better view of this new industry wide hot button I suggest that you come to
Richard Goering's panel at IVC on Weds., Feb 28th at the Santa Clara
Convention Center.  It should be an eye opener.

-------

John Cooley runs the grassroots E-mail Synopsys Users Group (ESNUG), is
president of the Users Society of Electronic Design Automation (USE/DA), and
makes his living as an independent contract ASIC/FPGA designer.  He loves
receiving e-mail from fellow engineers at "jcooley@world.std.com" or phone
(508) 429-4357.            [ Copyright 1995 CMP/EE Times Publications ]

============================================================================

            ONE READER'S RESPONSE (more are always welcome!)

From: Mahendra Jain, Executive Director, VHDL Int'l

Dear EE Times,

I'd like to respond to John Cooley's Industry Gadfly Column in last week's
issue.  Once again, I believe his comments are based on incomplete
information.  I hope you'll allow me to explain.

The VHDL/Verilog HDL wars are indeed over.  We do not believe there are any
wars.  The co-location of IVC/VIUF is a symbol that there's no war and, in
fact, shows that OVI and VHDL International are working together
cooperatively.

John Cooley's column discusses the preliminary HDL simulator revenues EDAC
released recently.  We think the information provided by EDAC is incomplete
and premature.  For example, we don't have information on number of units
sold or the average selling price per unit.  We believe these are key
factors and would probably show a different set of results.  Industry
research continues to show that designers are opting to use VHDL on a
worldwide basis.  VITAL libraries are only now becoming available and over
the next three to six months more will be introduced to support deep
submicron design.  VHDL International is publishing a table of available
VITAL Libraries in VHDL Times next month.

VHDL International isn't about comparing languages, simulators or revenues.
Our goal is to better serve the designer community by helping provide tools
to educate them, make their jobs easier and make them more productive.  The
EDA Community has the responsibility to provide both VHDL- and Verilog
HDL-based tools as long as it is what designers want.

As the Executive Director of VHDL International, I am disappointed that the
language war continues to be fueled by a seemingly neutral and responsible
industry observer.
                                      Best regards,

                                      Mahendra Jain
                                      Executive Director
                                      VHDL International

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 4126 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."

Article: 3015
Subject: Re: Xact6.o too slow
From: Mike Siersema <lear4@earthlink.net>
Date: 13 Mar 1996 23:45:44 GMT
Links: << >> << T >> << A >>

3/13/96

The computer that we use is a 66Mhz, 32Mram.

We used Xact 6.0 windows version and we discovered that it is too slow.  
Upon the advice of industry experts utilizing FPGA's, we do not compile 
our designs in the windows version because it is too slow.  Futhermore, 
ProSim is not usable.  Simulating in ProSim is a nightmare.  Some of our 
functional simulations (simulations done before routing) would take 20 
minutes to update on the screen and if you wanted to print the waveform 
of zoom in to a specific time period, that would take another 20 minutes 
to update.  I called the Xilinx support line to confirm that this windows 
version is too slow and they agreed.

The solution to your problem is to use Workview 5.1.0 dos version for 
your functional simulations and Procapture for your schematic capture. 
You can use any dos editor for your ABEL files. You can compile and merge 
in any dos version of Xact.

The real question is how will Xilinx create a more user friendly FPGA 
compile and simulation system without compromising too much speed.  If 
they do not create better software, somebody will.

Article: 3016
Subject: Re: Xact6.o too slow
From: Mike Siersema <lear4@earthlink.net>
Date: 13 Mar 1996 23:46:34 GMT
Links: << >> << T >> << A >>

3/13/96

The computer that we use is a 66Mhz, 32Mram.

We used Xact 6.0 windows version and we discovered that it is too slow.  
Upon the advice of industry experts utilizing FPGA's, we do not compile 
our designs in the windows version because it is too slow.  Futhermore, 
ProSim is not usable.  Simulating in ProSim is a nightmare.  Some of our 
functional simulations (simulations done before routing) would take 20 
minutes to update on the screen and if you wanted to print the waveform 
of zoom in to a specific time period, that would take another 20 minutes 
to update.  I called the Xilinx support line to confirm that this windows 
version is too slow and they agreed.

The solution to your problem is to use Workview 5.1.0 dos version for 
your functional simulations and Procapture for your schematic capture. 
You can use any dPierre Cluzel <cluzel@ipnl.in2p3.fr> wrote:
>I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
>years) and my first work has been to test the software with the tutorial
>example CALC.1.
>	I have never experienced crashes during schematic editing but the
>implementation software is very VERY SLOW . My machine configuration is
>: Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
>Version 3.1.
>	PPR running with DOS (xdm) takes about 2-3 min. to implement the
>tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
>the same job in the Windows version...!!
>Is my machine badly configured or Xactstep is really too slow ?
>Could some people do the same test and reply me the result for
>comparision and eventually modify my configuration files.
>
>Pierre CLUZEL
>Institut de Physique Nucleaire de Lyon
>43 boulevard du 11 Novembre
>F 69622 VILLEURBANNE CEDEX
>Phone : (33) 7244 8420
>Fax : (33) 7244 8004
>Email : cluzel@ipnl.in2p3.fr
os editor for your ABEL files. You can compile and merge 
in any dos version of Xact.

The real question is how will Xilinx create a more user friendly FPGA 
compile and simulation system without compromising too much speed.  If 
they do not create better software, somebody will.

Bill Weishaupt

Article: 3017
Subject: linux FPGA designenvironment ?
From: Robert.Larice@munich.netsurf.de
Date: 14 Mar 1996 12:23:52 GMT
Links: << >> << T >> << A >>

i have to update/upgrade/change our FPGA design environment.
currently we are designing with OrCAD and Xilinx under DOS.

now i would like to know whether there is any EDA-company out there
which supports linux as a platform for a FPGA design-environment.

preferable target technology is the Xilinx 3000 and 4000 family,
but thats not a must.

Thanx,
  Larice Robert

------------------------------------------------------------------------------
  ViDiSys GmbH & Co. KG               phone:  +49-8104-9499
  Rudolf-Diesel-Ring 30               fax:    +49-8104-1879
  D-82054 Sauerlach, Germany          e-mail: Robert.Larice@munich.netsurf.de

Article: 3018
Subject: FCCM'96 Preliminary Program
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Thu, 14 Mar 1996 13:35:54 GMT
Links: << >> << T >> << A >>

	IEEE Symposium on FPGAs for Custom Computing Machines
	      Marriott at Napa Valley, Napa, California
		      April 17 - April 19, 1996
			 Preliminary Program

Tuesday, April 16, 1996
7:00 - 9:00 PM                  Registration

Wednesday, April 17, 1996
8:00 AM                         Registration Opens
9:00    - 9:15 AM               Opening Remarks
9:15    - 10:00 AM              Invited Speaker: R. Parker, DARPA/ITO
                                    "DARPA and Configurable Computing"
10:00   - 10:30 AM              Break
10:30   - 12:00 PM              Session 1
12:00   - 1:30 PM               Lunch
1:30    - 3:00 PM               Session 2
3:00    - 3:30 PM               Break
3:30    - 5:00 PM               Session 3
5:00    - 7:00 PM               Open
7:00    - 9:00 PM               Vendor Openhouses

Thursday, April 18, 1996
8:00AM                          Registration opens
8:15    - 8:30 AM               Administrative updates
8:30    - 10:00 AM              Session 4
10:00   - 10:30 AM              Break
10:30   - 12:00 PM              Session 5
12:00   - 1:30 PM               Lunch
1:30    - 3:00 PM               Session 6
3:00    - 3:15 PM               Break
3:15    - 4:45 PM               Panel Chaired by B. Hutchings, BYU
4:45    - 6:30 PM               Open
6:30    - 10:00 PM              Dinner Activity (optional)

Friday, April 19, 1996
8:00 AM                         Registration opens
8:15    - 8:30 AM               Administrative updates
8:30    - 10:00 AM              Session 7
10:00   - 10:30 AM              Break
10:30   - 12:00 PM              Session 8
12:00   - 12:30 PM              Closing Remarks & Feedback for next year



 
Wednesday, April 17, 1996 (Day 1)

Session 1:  Applications I
        Title:             VLSI Architecture for FPGAs: A Case Study
        Authors:           R. Woods, A. Cassidy and J. Gray
        Organizations:     The Queen's University of Belfast and Xilinx

        Title:             Assessing Document Relevance with Run-Time    
                             Reconfigurable Machines
        Authors:           B. Gunther, G. Milne, and L. Narasimhan
        Organization:      University of South Australia

        Title:             Using MORPH in an Industrial Machine Vision   
                             System
        Authors:           W. King, T. Drayer, R. Conners, P. Araman
        Organizations:     Nova Technologies, Virginia Polytechnic       
                             Institute & State University


LUNCH


Session 2:  Compiler and Software Issues I 
        Title:             A Software Development System for FPGA-Based  
                              Data Acquisition Systems
        Authors:           G. Brown, A. Wenban
        Organization:      Cornell University

        Title:             Bit-Serial Pipeline Synthesis for Multi-FPGA  
                              Systems with C++ Design Capture
        Authors:           W. Dai, T. Isshiki
        Organization:      University of California at Santa Cruz

        Title:             Revisiting Smalltalk-80 blocks: A logic       
                              generator for FPGAs
        Authors:           B. Pottier
        Organization:      Univesite de Bretagne Occidentale


Session 3:  Applications 2
        Title:             RACER: A Reconfigurable Constraint-Length 14  
                              Viterbi Decoder
        Authors:           D. Yeh, G. Feygin, P. Chow
        Organization:      University of Toronto

        Title:             Configurable Computing Solutions for          
                              Automatic Target Recognition
        Authors:           J. Villasenor, B. Schoner, K.N. Chia, 
                              C. Zapata
        Organization:      University of California at Los Angeles

        Title:             Exploring Architectures for Volume            
                           Visualization on the Teramac Custom Computer
        Authors:           W.B. Culbertson, R. Amerson, R.J. Carter, 
                             P. Kuekes, G. Snider
        Organization:      Hewlett-Packard



 Thursday, April 18, 1996 (Day 2)

Session 4:  Education
        Title:          Using Rapid Prototyping to Teach the Design of   
                           Complete Computing Solutions
        Authors:        P. Athanas, R. Hudson
        Organization:   Virginia Polytechnic Institute and 
                           State University

        Title:          Aizup - A Pipelined Processor Design &           
                           Implementation on Xilinx FPGA chip
        Authors:        W. Chu, Y. Li
        Organization:   University of Aizu

        Title:          Implementation of IEEE Single Precision Floating 
                          Point Addition and Multiplication on FPGAs
        Authors:        T.A. Cook, L. Louca, W.H. Johnson
        Organizations:  Rutgers University


Session 5:  Hybrid Systems
        Title:          Mixing Fixed and Reconfigurable Logic for Array  
                          Processing
        Authors:        P.J. Bakkes, J.J. duPlessis, B.L. Hutchings
        Organizations:  U. of Stellenbosch and Brigham Young University

        Title:          OneChip: An FPGA Processor with Reconfigurable   
                           Logic
        Authors:        R. Wittig, P. Chow
        Organization:   University of Toronto

        Title:          A PCI-compatible FPGA-Coprocessor for 2D/3D      
                          Image Processing
        Authors:        G. Knittel
        Organization:   University of Tubingen


LUNCH
 

Session 6:  Systems
        Title:          SOP: A Reconfigurable Massively Parallel System  
                        and Its Control-Data-Flow based Compiling Method
        Authors:        T. Yamauchi, S. Nakaya, N. Kajihara
        Organization:   NEC

        Title:          MATRIX: A Reconfigurable Computing Architecture  
                        with Configurable Instruction Distribution and   
                        Deployable Resources
        Authors:        E. Mirsky, A. DeHon, 
        Organization:   Massachusetts Institute of Technology

        Title:          Modelling and Optimising Run-Time Reconfigurable 
                          Systems
        Authors:        W. Luk, N. Shirazi, P. Cheung
        Organization:   Imperial College


Panel Session:  Can configurable computers be general-purpose computers?
        Chair:          Brad Hutchings, BYU
        Panelists:      Peter Athanas, Virginia Tech.
                        Brian Box, Lockheed Sanders
                        Philip Freidin, Fliptronics
                        Phil Kuekes, HP Labs
                        John McHenry, Department of Defense
                        Mark Shand, Digital Equipment Corp.
                        Richard Shoup, Interval Research



Friday, April 19, 1996 (Day 3)

Session 7:  Compiler and Software Issues II
        Title:          Scheduling and Partitioning ANSI-C Programs onto 
                          Multi-FPGA CCM Architectures
        Authors:        J. B. Peterson, R. B. O'Connor, P. M. Athanas
        Organization:   Virginia Polytechnic Institute and State         
                          University

        Title:          Expressing Dynamic Reconfiguration by Partial    
                           Evaluation
        Authors:        S. Singh, J. Hogg, D. McAuley
        Organization:   University of Glasgow

        Title:          The DISC Programming Environment
        Authors:        D. A. Clark, B. L. Hutchings
        Organization:   Brigham Young University


Session 8:  Comparative Analysis
        Title:          On the Viability of FPGA-based Integrated        
                        Coprocessors
        Authors:        O. T. Albahama, P. Cheung, T. J. Clarke
        Organization:   University of London

        Title:          Genetic Algorithms in Software and in Hardware - 
                        A Performance Analysis of Workstations and       
                        Custom Computing Machine Implementations
        Authors:        P. Graham, B. Nelson
        Organization:   Brigham Young University

        Title:          A Quantitative Analysis of Processor -           
                          Programmable Logic Interface
        Authors:        S. Rajamani, P. Viswanath
        Organization:   University of California at Berkeley

Article: 3019
Subject: FCCM'96 Registration
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Thu, 14 Mar 1996 13:37:39 GMT
Links: << >> << T >> << A >>

                                                           02/6/96
                 REGISTRATION AND HOTEL INFORMATION
IEEE Symposium on FPGAs for Custom Computing Machines, April 17-19, 1996
            Marriott at Napa Valley, Napa, California
              3425 Solano, Napa, California 94558
                707-253-7433, 707-258-1320 (fax)

Accommodation arrangements should be made directly with the hotel.  The
special FCCM'96 rate is $89/night, single or double occupancy.  Hotel
rates are subject to applicable state and local taxes, currently
$12/night. 

PLEASE TYPE OR PRINT

Name    ___________________________________________________________

Address ___________________________________________________________

        ___________________________________________________________

        ___________________________________________________________

Email   ___________________________________________________________

Phone   ____________________________   Fax ________________________

Active IEEE Member Number (Y/N)? ___   Member No: _________________

Registration Fee (see table below):  $_____________________________

Credit Card Payers:
Card Holder's Name    _____________________________________________

Card Type(MC, Visa)   _________________  Exp Date__________________

Card Number           _____________________________________________

Signature             _____________________________________________

(Credit card payment cannot be made by email--a signature is required)
Student registrants:
I certify that I am a registered student at _______________________

(signed) __________________________________________________________

University address:________________________________________________

The registration fee schedule is as follows. The deadline for
preregistration is March 22, 1996.  Regular (nonstudent)
registration includes a copy of the proceedings and lunch on
Wednesday and Thursday, April 17 and 18.

               Preregistration    Onsite Registration
IEEE Members        220                 270
Non-Members         300                 360
Students             90                 110

All rates are U. S. dollars.  Checks must be drawn on a U.S. bank
and should be made payable to IEEE FCCM Symposium.  Checks and
registration forms should be mailed to IEEE FCCM Symposium,
c/o Ken Pocek, Intel, Mailstop RN6-18, 2200 Mission College Blvd.,
Santa Clara, CA  95052 (USA).

Article: 3020
Subject: Re: Xact6.o too slow
From: Lance Gin <c43lyg@dso.hac.com>
Date: 14 Mar 1996 21:10:17 GMT
Links: << >> << T >> << A >>

Pierre Cluzel <cluzel@ipnl.in2p3.fr> wrote:
>I've been using XACT step 6.0.0 for one month ( XACT 4.0 for several
>years) and my first work has been to test the software with the tutorial
>example CALC.1.
>	I have never experienced crashes during schematic editing but the
>implementation software is very VERY SLOW . My machine configuration is
>: Processor Intel 486 DXII 66 MHz, RAM 32 Mb , dos version 6.2, Windows
>Version 3.1.
>	PPR running with DOS (xdm) takes about 2-3 min. to implement the
>tutorial calc.1 into a 3020APC68 , and more than 1 hour 30 min. to do
>the same job in the Windows version...!!
>Is my machine badly configured or Xactstep is really too slow ?
>Could some people do the same test and reply me the result for
>comparision and eventually modify my configuration files.
>

bonjour pierre,

we are a new xilinx customer and are about to embark on the design of an
XC4025E (a relatively large xilinx device). i can't give you any details
since we don't have any experience yet. however, i can tell you that when
i called the xilinx tech hotline and asked for a platform recommendation,
they told me that they highly recommend we use xact 5.2 (unix) rather than
xact 6.0 (PC). apparantly, some customers have been experiencing performance
problems on P5 PC's with 64mb+ RAM. 

i do believe xilinx is recommending a
minimum of 64Mb RAM (don't know details on swap setup). hope this helps.

-- 
_______________________________________________________________________

Lance Gin                                         "off the keyboard
Delco Systems - GM Hughes Electronics              over the bridge,
OFC: 805.961.7737  FAX: 805.961.7329               through the gateway,
C43LYG@dso.hac.com                                 nothing but NET!"
_______________________________________________________________________

Article: 3021
Subject: PDW'96 Advance Program
From: pdw96@casper.cs.virginia.edu
Date: Fri, 15 Mar 1996 02:00:56 GMT
Links: << >> << T >> << A >>


Dear Colleague,

   Enclosed below is the advance program for the 1996 ACM/SIGDA
Physical Design Workshop, which is co-sponsored the U.S. National
Science Foundation.

   This year's workshop will emphasize deep-submicron and
high-performance issues, and will also feature a special track on
micro electromechanical systems (MEMS), chaired by Ken Gabriel of ARPA.

For more information, please see our WWW home page at:

   http://www.cs.virginia.edu/~pdw96/

Please pass along this advance program to your collagues.

Thanks,

Gabe

p.s.  Please note that the the hotel room reservation deadline is
      March 24.  In order to promote free-flowing discussion among the
      participants, attendance in this workshop will be limited, so we
      encourage you to register soon.

======================================================
Name:           Prof. Gabriel Robins
                General Chair, PDW'96
U.S. Mail:      Department of Computer Science
                Thornton Hall
                University of Virginia
                Charlottesville, VA 22903-2442
Phone:          (804) 982-2207
FAX:            (804) 982-2214
E-mail:         robins@cs.virginia.edu
WWW:            http://www.cs.virginia.edu/~robins/
======================================================

=============================================================================

                           ADVANCE PROGRAM

               Fifth ACM/SIGDA Physical Design Workshop
 April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA

                  http://www.cs.virginia.edu/~pdw96/


The ACM/SIGDA Physical Design Workshop (PDW'96) provides a relaxed
atmosphere for exchange of ideas and promotes research in critical
subareas of physical design for VLSI systems.

This year's workshop emphasizes deep-submicron and high-performance
issues, and also provides a special focus on opportunities in CAD for
micro electromechanical systems (MEMS).  There are four outstanding
panel sessions:

 (1) future needs and directions for deep-submicron physical design,

 (2) physical design needs for MEMS,

 (3) manufacturing and yield issues in physical design, and 

 (4) critical disconnects in design views, data modeling, and back-end
     flows (e.g., for physical verification).

There are also many outstanding technical paper sessions.
Free-flowing discussion will be promoted through the limited workshop
attendance, the poster session and the "open commentary" mechanism in
each technical session, as well as a concluding open problems session.
During the workshop, a benchmarks competition will occur in the areas
of netlist partitioning and performance-driven cell placement.

=============================================================================
                           SUNDAY, APRIL 14
=============================================================================

6:00pm-8:30pm: Registration
  (the registration desk will also be open 8:00am-5:00pm on Monday
   and 8:00am-12:00pm on Tuesday)

7:00pm-8:30pm: Reception (refreshments provided)

=============================================================================
                           MONDAY, APRIL 15
=============================================================================

8:30am-8:40am: Welcome

8:40am-10:00am: Session 1, Timing-Driven Interconnect Resynthesis

  Interconnect Layout Optimization by Simultaneous Steiner Tree
  Construction and Buffer Insertion, T. Okamoto and J. Cong (UC Los Angeles)

  Simultaneous Routing and Buffer Insertion for High Performance
  Interconnect, J. Lillis, C.-K. Cheng and T.-T. Lin (UC San Diego)

  Timing Optimization by Redundancy Addition/Removal, L. Entrena, E. Olias
  and J. Uceda (U. Carlos III of Madrid and U. Politecnica of Madrid) 

  Open Commentary - Moderators: D. Hill (Synopsys),
                                P. Suaris (Interconnectix)

10:00am-10:20am: Break

10:20am-12:00pm: Session 2, Interconnect Optimization

  Optimal Wire-Sizing Formula Under Elmore Delay Model, 
  C. P. Chen, Y. P. Chen and D. F. Wong (U. Texas Austin)

  Reducing Coupled Noise During Routing, A. Vittal and M. Marek-Sadowska 
  (UC Santa Barbara) 

  Simultaneous Transistor and Interconnect Sizing Using General
  Dominance Property, J. Cong and L. He (UC Los Angeles)

  Hierarchical Clock-Network Optimization, D. Lehther, S. Pullela, 
  D. Blaauw and S. Ganguly (Somerset Design Center and Motorola) 

  Open Commentary - Moderators: D. Hill (Synopsys),
                                M. Lorenzetti (Mentor)

12:00pm-2:00pm: Lunch

  Workshop Keynote Address: Prof. C. L. Liu, U. of Illinois
  Algorithmic Aspects of Physical Design of VLSI Circuits

2:00pm-2:45pm: Session 3, A Tutorial Overview of MEMS

  Speaker: K. Gabriel (ARPA)

2:45pm-3:00pm: Break

3:00pm-4:15pm: Session 4, Physical Design for MEMS

  Physical Design for Surface Micromachined MEMS, Gary K. Fedder and
  Tamal Mukherjee (Carnegie-Mellon U.)

  Physical Design Support for MCNC/MUMPS, R. Mahadevan (MCNC)

  Synthesis and Extraction for MEMS Design, E. Berg, N. Lo and 
  K. Pister (UC Los Angeles)

4:15pm-4:30pm: Break

4:30pm-6:00pm: Session 5, Panel: Physical Design Needs for MEMS

  Moderator: K. Pister (UC Los Angeles)

  Panelists include:
    S. Bart (Analog Devices)
    G. Fedder (Carnegie-Mellon U.)
    K. Gabriel (ARPA)
    I. Getreu (Analogy)
    R. Grafton (NSF)
    R. Mahadevan (MCNC)
    J. Tanner (Tanner Research)

6:00pm-8:00pm: Dinner

8:00pm-9:30pm: Session 6, Panel: Deep-Submicron Physical Design:
                          Future Needs and Directions

  Panelists include:
    T. C. Lee (former VP Eng, SVR;  President/CEO, Neo Paradigm Labs)
    L. Scheffer (Architect, Cadence) 
    W. Vercruysse (UltraSPARC III CAD Manager, Sun) 
    M. Wiesel  (CAD Manager, Intel) 
    T. Yin (VP R&D, Avant!) 

=============================================================================
                          TUESDAY, APRIL 16
=============================================================================

8:30am-9:50am: Session 7, Partitioning



  VLSI Circuit Partitioning by Cluster-Removal Using Iterative Improvement 
  Techniques, S. Dutt and W. Y. Deng (U. Minnesota and LSI Logic)

  A Hybrid Multilevel/Genetic Approach for Circuit Partitioning,
  C. J. Alpert, L. Hagen and A. B. Kahng (UC Los Angeles and Cadence)

  Min-Cut Replication for Delay Reduction, J. Hwang and A. El Gamal
  (Xilinx and Stanford U.)

  Open Commentary - Moderators: J. Frankle (Xilinx),
                                L. Scheffer (Cadence)

9:30am-10:10am: Break

10:10am-11:50am: Session 8, Topics in Hierarchical Design

  Two-Dimensional Datapath Regularity Extraction, R. Nijssen and 
  J. Jess (TU Eindhoven)

  Hierarchical Net Length Estimation, G. Zimmermann (U. Kaiserslautern)

  Exploring the Design Space for Building-Block Placements Considering
  Area, Aspect Ratio, Path Delay and Routing Congestion,  H. Esbensen and 
  E. S. Kuh (UC Berkeley)

  Genetic Simulated Annealing and Application to Non-Slicing Floorplan
  Design, S. Koakutsu, M. Kang and W. W.-M. Dai (Chiba U. and UC Santa Cruz) 

  Open Commentary

11:50pm-1:30pm: Lunch


1:30pm-3:00pm: Session 9, Poster Session

  Physical Layout for Three-Dimensional FPGAs, M. J. Alexander, J. P.
  Cohoon, J. Colflesh, J. Karro, E. L. Peters and G. Robins (U. of Virginia)

  Efficient Area Minimization for Dynamic CMOS Circuits, B. Basaran
  and R. Rutenbar (Carnegie-Mellon U.)

  A Fast Technique for Timing-Driven Placement Re-engineering,
  M. Hossain, B. Thumma and S. Ashtaputre (Compass Design Automation)

  An Approach to Layout and Process Verification for Microsystem,
  Physical Design, K. Hahn and R. Bruck (U. Dortmund) 

  Computer  Aided Micro-Machining for Wet Etch Fabrication,
  M. K. Long, J. W. Burdick and T. J. Hubbard (Caltech)

  Over-the-Cell Routing with Vertical Floating Pins, I. Peters, P. Molitor
  and M. Weber (U. Halle and Deuretzbacher Research GmbH)

  Congestion- Balanced Placement for FPGAs, R. Sun, R. Gupta and C. L. Liu 
  (Altera and U. Illinois)

  Fanout Problems in FPGA, K.-H. Tsai, M. Marek-Sadowska and S. Kaptanoglu
  (UC Santa Barbara and Actel)

  An Optimal Pairing and Chaining Algorithm for Layout Generation,
  J. Velasco, X. Marin, R. P. Llopis and J. Carrabina (IMB-CNM
  U. Autonoma de Barcelona, Philips Research Labs Eindhoven)

  Clock-Delayed Domino in Adder and Random Logic Design, G. Yee and 
  C. Sechen (U. Washington)


3:00pm-4:00pm: Session 10, Manufacturing/Yield Issues I

  Layout Design for Yield and Reliability, K. P. Wang, M. Marek-Sadowska 
  and W. Maly (UC Santa Barbara and Carnegie-Mellon U.)

  Yield Optimization in Physical Design, V. Chiluvuri (Motorola) 
  (invited survey paper)

4:00pm-4:15pm: Break

4:15pm-5:45pm: Session 11, Panel: Manufacturing/Yield Issues II

  Panelists include:
    V. Chiluvuri (Motorola)
    I. Koren (U. Massachusetts Amherst)
    J. Burns (IBM Watson Research Center)
    W. Maly (Carnegie-Mellon U.)

5:45pm-7:30pm: Dinner

7:30pm-9:30pm: Session 12, Panel: Design Views, Data Modeling and
                           Flows: Critical Disconnects
  A Talk by C. Sechen (U. Washington)

  A Gridless Multi-Layer Channel Router Based on Combined Constraint Graph
  and Tile Expansion Approach, H.-P. Tseng and C. Sechen (U. Washington)

  A Multi-Layer Chip-Level Global Route, L.-C. E. Liu and C. Sechen
  (U. Washington)

  Panelists include:
    W. W.-M. Dai (UC Santa Cruz, VP Ultima Interconnect Technologies)
    L. Jones (Motorola)
    D. Lapotin (IBM Austin Research Center)
    E. Nequist (VP R&D, Cooper & Chyan)
    R. Rohrer (Chief Scientist, Avant!)
    P. Sandborn (VP, Savantage)

=============================================================================
                         WEDNESDAY, APRIL 17
=============================================================================

8:30am-9:50am: Session 13, Performance-Driven Design

  A Graph-Based Delay Budgeting Algorithm for Large Scale Timing-Driven
  Placement Problems, G. Tellez, D. A. Knol and M. Sarrafzadeh 
  (Northwestern U.)

  Reduced Sensitivity  of Clock Skew Scheduling to Technology Variations,
  J. L. Neves and E. G. Friedman (U. Rochester) 

  Multi-Layer Pin Assignment for Macro Cell Circuits, L.-C. E. Liu and
  C. Sechen (U. Washington)

  Open Commentary

9:50pm-10:10pm: Break

10:10am-11:30am: Session 14, Topics in Layout

  Constraint Relaxation in Graph-Based Compaction, S. K. Dong, P. Pan,
  C. Y. Lo and C. L. Liu (Silicon Graphics, Clarkson U., Lucent, U. Illinois)

  An O(n) Algorithm for Transistor Stacking with Performance Constraints,
  B. Basaran and R. Rutenbar (Carnegie-Mellon U.)

  Efficient Standard Cell Generation When Diffusion Strapping is Required,
  B. Guan and C. Sechen (Silicon Graphics and U. Washington)

  Open Commentary - Moderator: A. Domic (Cadence)

11:30am-12:00pm: Session 15, Open Problems

  Moderators: A. B. Kahng (UC Los Angeles), B. Preas (Xerox PARC)

12:00pm-2:00pm: Lunch (and benchmark competition results)

2:00pm: Workshop adjourns

=============================================================================
                       TRAVEL AND ACCOMODATIONS
=============================================================================

PDW '96 is being held at the Sheraton Reston in Reston, Virginia, near
Washington, D.C.  The hotel is minutes from Dulles International
Airport (IAD), and 24-hour courtesy shuttles are available from the
airport to the hotel.  The area is also served by Washington National
Airport (DCA), about 20 miles away, and Baltimore-Washington
International Airport (BWI), about 50 miles away.

The Sheraton Reston is located at:
  11810 Sunrise Valley Drive
  Reston, Virginia 22091
  phone: 703-620-9000
  fax: 703-860-1594
  reservations: 800-392-ROOM

*** Please make your room reservation directly with the Reston ***
*** Sheraton hotel.                                            ***

Driving directions from Dulles Airport: take the Washington Dulles
Access and Toll Road (route 267) to the Reston Parkway Exit (3).  Turn
right at the light after paying toll.  Take the next left onto Sunrise
Valley Drive, and continue for a couple blocks to the Sheraton (on
your left).

A block of rooms is being held for the nights of Sunday through
Wednesday (April 14 through April 17). Room rates are $95 per night
for single occupancy, and $105 per night for double occupancy. The
number of rooms available at these rates is limited, and they are only
being held through March 24 (so early registration is highly recommended).

The Washington D.C. weather tends to be chilly in April, so warm dress
is suggested for the outdoors.

=============================================================================
                     SIGHTSEEING AND ATTRACTIONS
=============================================================================

The Nation's Capitol offers much in the way of sightseeing.  The most
popular destinations are located in downtown Washington D.C.,
surrounding several square miles of park area known as the "National
Mall."  There is no charge to visit the National Memorials located on
the Mall, which include the Washington Monument, where you may ascend
555 feet to an observation post; the Lincoln Memorial, whose design
adorns the back of the US penny; the Jefferson Memorial, which
includes a 19-foot bronze statue of Thomas Jefferson; and the Vietnam
Memorial, a long wall of black Indian granite dedicated in 1982.

The Smithsonian Institution (telephone (202) 357-2700) operates a
number of superb museums that flank the National Mall, including:

  Freer Gallery of Art (Asian and 19th and 20th-century American art)
  Hirshhorn Museum and Sculpture Garden (modern and contemporary art)
  National Air and Space Museum (history of aviation and space exploration)
  National Museum of African Art (collection and study of African art)
  National Museum of American Art (paintings, graphics, and photography)
  National Museum of American History (technology and culture in America)
  National Museum of Natural History (history of the natural world)
  National Portrait Gallery (portraits of distinguished americans)
  National Postal Museum (history of postal communication and philately)
  Sackler Gallery of Asian art (from ancient to present)

Other attractions and tours around the D.C. area include (please call
the numbers below for schedules):

  Arlington National Cemetary (703) 697-2131
  Bureau of Engraving and Printing (202) 622-2000
  Congressional buildings (202) 225-6827
  FBI Headquarters (202) 324-3447
  Library of Congress (202) 707-5000
  National Aquarium (202) 482-2825
  National Archives (202) 501-5000
  National Zoological Park (202) 673-4821
  The Pentagon (703) 695-1776
  Supreme Court (202) 479-3030
  Treasury Department (202) 622-2000
  The White House (202) 456-7041

There are a number of reasonably priced eating places on the Mall; the
East Wing of National Gallery and the Air and Space Museums offer good
food and a place to sit down after sightseeing.  Provisions will be
made for low-cost transportation to and from the Mall and downtown
Washington D.C., so bring your camera and strolling shoes and enjoy
our Nation's Capital!

=============================================================================
WORKSHOP ORGANIZATION
=============================================================================

General Chair: 

  G. Robins (U. of Virginia)

Technical Program Committee:

  C. K. Cheng (UC San Diego)
  J. P. Cohoon (U. of Virginia)
  J. Cong (UC Los Angeles)
  A. Domic (Cadence)
  J. Frankle (Xilinx)
  E. Friedman (Rochester)
  D. Hill (Synopsys)
  L. Jones (Motorola)
  A. B. Kahng (UC Los Angeles, Chair)
  Y.-L. Lin (Tsing Hua)
  K. Pister (UC Los Angeles)
  M. Marek-Sadowska (UC Santa Barbara)
  C. Sechen (Washington)
  R.-S. Tsay (Avant!)
  G. Zimmermann (Kaiserslautern)

Steering Committee:

  M. Lorenzetti (Mentor Graphics)
  B. Preas (Xerox PARC)

Keynote Address:

  C. L. Liu (Illinois)

Benchmarks Co-Chairs:

  F. Brglez (NCSU)
  W. Swartz (TimberWolf Systems)

Local Arrangements Chair:

  M. J. Alexander (U. of Virginia)

Treasurer:

  S. B. Souvannavong (HIMA)

Publicity Chair:

  J. L. Ganley (Cadence)

Sponsors:

  ACM / SIGDA
  U.S. National Science Foundation
  Avant! Corporation

=============================================================================
                        WORKSHOP REGISTRATION
=============================================================================

               Fifth ACM/SIGDA Physical Design Workshop
 April 15-17, 1996 - The Sheraton Reston Hotel, Reston, Virginia USA

Name: _______________________________________________________________

Company/University: _________________________________________________

Title: ______________________________________________________________

Address: ____________________________________________________________

City: _________________________________________ State: ______________

Phone: ____________________________ Email: __________________________


                Registration Fees (Includes All Meals)

              Advance (Through April 1)  Late (After April 1/On-Site)
ACM Members         __ $355                      __ $440
Non-ACM             __ $455                      __ $540
Students            __ $250                      __ $250

         ACM Membership Number: _____________________________

         Dietary restrictions, if any: ______________________

         Special needs: _____________________________________

The registration fee includes the workshop proceedings and all meals
(i.e., 3 breakfasts, 3 lunches, and 2 dinners), refreshments during
breaks, and a reception on Sunday evening.  The total number of
attendees is limited (registrations will be returned if the workshop
is oversubscribed).

*** Note: Hotel reservations must be made directly with the Sheraton ***
*** (see above).                                                     ***

The only acceptable forms of payment are checks (personal, company,
and certified/bank checks) in US funds drawn on a US bank and made
payable to "1996 Physical Design Workshop" (credit cards will not be
accepted).  Payment must accompany your registration. No FAX or Email
registrations will be processed.

Please mail your payment (checks only) along with this registration form to:

  Sally Souvannavong, Treasurer
  1996 ACM/SIGDA Physical Design Workshop
  Department of Computer Science
  Thornton Hall
  University of Virginia
  Charlottesville, VA 22903-2442 USA

  Phone: (804) 982-2200
  Email: pdw96@cs.virginia.edu

Cancellations must be in writing and must be received by March 31, 1996.

=============================================================================
The Latex and postscript versions of this advanced program may be
obtained from http://www.cs.virginia.edu/~pdw96/
=============================================================================

Article: 3022
Subject: Pointers?
From: mbutts@netcom.com (Mike Butts)
Date: Fri, 15 Mar 1996 07:18:13 GMT
Links: << >> << T >> << A >>

A very big issue that I haven't heard discussed in this fine
little forum that's gotten going here, is the assumption that
computer languages like C have of a single, large, linearly
addressed memory for storing data in, that you can point
into with address variables.

Examples like little arithmetic functions are well and good,
but real C programs have pointers.  Pointers that can be
assigned to at run time, with run-time-computed values.
I'm certainly not a compiler expert, but those who are cite
pointer aliasing as a substantial impediment to automatic
parallelization of old code.

The problem crops up if pointers 'a' and 'b' both get computed
at run time, such that the compiler has no way of knowing
for sure that they don't both point to the same location.
Which opens the possibility of all the synchronization
hazards that result from reordering execution of serial code.
Example: *a = m; n = *b;  If a=b at run time, you've passed data
from m to n, if not you haven't.  You can't tell which at
compile time.  Or how about *a = m; *b = n; p = *a;  Does
p = m?  Can you switch around the execution order of the first
two, seemingly unrelated statements?  Or run them in parallel?

In reconfigurable hardware programmed in C, how does the
compiler figure out how many memories of what size exist,
and who reads and writes which memories when?  One big
memory with one port is the wrong answer, for the only hope
of reconfigurable computing to get worthwhile (=massive)
performance gains is to bust open the processor-memory
bottleneck intrinsic in the existing model.

Did I read someplace that Java has no pointers?  I haven't
looked it up yet.  Is FORTRAN the language of the future?
( 1/2 :-)

                        --Mike

-- 
Mike Butts, Portland, Oregon   mbutts@netcom.com

Article: 3023
Subject: Re: Pointers?
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 15 Mar 1996 15:25:37 GMT
Links: << >> << T >> << A >>

>>>>> "MB" == Mike Butts <mbutts@netcom.com> writes:
In article <mbuttsDoAsAD.109@netcom.com> mbutts@netcom.com (Mike Butts) writes:

    MB> Did I read someplace that Java has no pointers?  I haven't
    MB> looked it up yet.  Is FORTRAN the language of the future?  (
    MB> 1/2 :-)

Reminds me of a joke I heard many years ago:

Two engineers are excitedly talking about the newest programming language...

"So, what about this new language for the year 2000?", one engineer
says to the other.  "Its great! Its high performance and its got every
feature you could want. In fact, they just keep extending the language
to ensure that it has every feature you might want." "Wow", says the
other engineer, "whats the name of this new language?". "Fortran",
says the other.

(rim-shot)

Ever since it came out, Fortran has always been the language of the future. :-)

Sorry, I couldn't help it.

Fortran has always been more of a subscription service than a language. :-)

Article: 3024
Subject: Re: Multiple FPGA Partitioning
From: RichAp@codemast.demon.co.uk (Richard Aplin)
Date: Fri, 15 Mar 1996 18:43:19 GMT
Links: << >> << T >> << A >>

ejessen@ix.netcom.com (Erik Jessen) wrote:

>Altera has software that will do the auto-partitioning for you.

Hmmm. I did a design about 3-4 years ago that used an Altera EPM7256, and
eventually overflowed it. The software routed it onto two chips, but the bugger
_never_ worked. I spent ages hand-wiring a new 2-chip prototype, about three
times longer triple-checking EVERY connection, and it simply did nothing. It
wasn't a speed problem, it wasn't a race condition, I even got some other guys
in the states to build one, and I never did find out what the problem was. The
solution? I re-did the whole thing using Actel FPGAs, which got it all on one
chip, ran faster, and saved the project.

Never bothered with Altera for anything except glue logic since. Mind you, the
FLEX series might be ok.

Just my $0.02.

Richard Aplin.

Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search