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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Messages from 475

Article: 475
Subject: Re: Help: Seeking Your Opinion of EDN Article
From: John Williams <jwill@chromatic.com>
Date: 30 Nov 1994 01:45:04 GMT
Links: << >>  << T >>  << A >>
> So- I think benchmarks are good, in general, but authors need to make sure
> not to obscure the impact on the total design methodology by too narrow
> a focus on individual tasks.

One thing I think vendors have to guard against is the temptation
to offer a methodology as a product. Engineers are a fairly
sophisticated bunch who generally prefer to define their own
methodology. I know I really go for the superior point tools rather
than go with something that attempts to address the methodology:

1) You need to know what the tool and the methodology is doing
anyways, obscuring it behind layers of automation doesn't make
it any easier.

2) You wind up with a methodology that you're not really happy with,
because your optimal approach isn't marketable.

3) You don't have as much of a choice in point tools and have to
settle for what ever happens to be integrated in the suite.

The tools that have really made it in the market have been the ones
based on standards and interoperability ( and performance, of course ).
Vendors have been offering GUI EDA frameworks for a while, but they'll
never catch on. Users are more concerned with the business end of
the tool, rather than the handle.

						John Williams



Article: 476
Subject: Bit Serial ?
From: glenn@my21.sm.luth.se (Glenn Jennings)
Date: Wed, 30 Nov 1994 08:04:09 GMT
Links: << >>  << T >>  << A >>
  Hi, we would like to build some BIT-SERIAL circuits and watch them run
on our FPCB/FPLDs.

  We would appreciate any pointers to texts, articles, people, even companies
that could tell us about the finesses of designing, for example, a hand-held
calculator.  We need help on every possible level, ANY feedback would be
appreciated please:

  * bit-serial arithmetic (even floating-point)
  * problems with control of bit-serial datapaths
  * memory/register design for bit-serial access
  * clever "canned" designs (described maybe in VHDL, BDS, even as gate
      netlists) for adding, multiplying, etc.
  * "definitive works" on the subject

  "Nibble-wide" techniques would also be interesting, but for pedagogical
reasons it would be easier to stick with single-bit-serial to begin with.

  About all I am aware of myself are Peter Denyer's books (U. Edinburgh), 
these date back to 1985 as I recall, the focus was on full-custom VLSI 
implementation and there was no discussion on controlling the datapath 
(just, "there exists a controller").

  If it matters we're working with the ORCA FPLD, on an APTIX GP4, and our
front-end is an RTL capture tool, and/or Viewlogic.

Thanks !

   Glenn Jennings                                 Email:     glenn@sm.luth.se
   Div.  of  Computer Engineering    Tel: (+46)920-91763  Alt: (+46)920-91000
   Lulea University of Technology    Fax: (+46)920-72191  Alt: (+46)920-97288
   S-971 87   Lulea,       SWEDEN                 LaTeX:            Lule{\aa}


Article: 477
Subject: Image processing on FPGAs (Comett student period)
From: pottier@ubolib.univ-brest.fr (Bernard Pottier)
Date: 30 Nov 1994 10:25:14 GMT
Links: << >>  << T >>  << A >>

---------------------------------------------------------------------------------
    			(STUDENT  PERIOD  OFFERED  in FRANCE)

     			  IMAGE  PROCESSING  on  FPGAs


                     		Thomson CSF and LIBr
                                        Brest

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


1     CONTEXT

The project concerns a programming environment for a dedicated programmable
electronic board including (a local net of) 6 FPGAs. This board has been devel-
oped last year in Thomson, and will be the hardware support for a PHD dealing
with its customization using a high level and full-integrated programming lan-
guage. This project will essentially deal with signal and image processing, and
the PHD is to begin in the coming weeks.


            We are looking for a student to work jointly with
                  the PHD candidate on this subject.


   The project is located in Brest, and is led jointly by Thomson/RCM/CEB
and Brest computer science laboratory (LIBr at U.B.O.).



2     COMETT PROJECT

( A preference will be given to candidates from Northern Europe.)

The COMETT student will work upon the first implementation of image /
signal processing algorithms on the multi-FPGAs board, using mainly existing
tools such as the Xilinx programming environment. This implementation will
follow as far as possible the state of the art of parallel or systolic design, but
the main goal is to have first the board running with a "real" algorithm.
   So the student has to know about Xilinx, FPGAs, Unix, C language, parallel
and systolic solutions, ... He/she might also have already worked on signal or
image processing. Moderate french speaking needed.
   The work will be done in collaboration with the PHD student, and with
Brest University Parallelism lab (LIBr).  It could be a 4 or 5 months period,
during 95 (no real constraints for the moment). May be the best would be from
April/May to August/September, so that the PHD student could have begun
to work on the subject, and give a better help to the COMETT student.
   While Thomson cannot receive a foreigner permanently, the work will be
based at university lab, and the student will be "invited" two or three days a
week in Thomson (that is a detail, but it is good to know there will be two work
places).
   Financing is half Thomson half COMETT, and it is expected to be about
4000 francs per month.  A "student room" would be available at a moderate
cost.



3   CONTACTS / FOLLOWING DETAILS

Please contact either :


Gilles Craignou at Thomson-CSF/RCM/CEB
tel (33) 98.31.23.67 or fax (33) 98.31.25.23
   or


Bernard Pottier at U.B.O.
tel (33) 98.01.62.15 or fax (33) 98016131
e-mail pottier@univ-brest.fr

__________________________________________________________________________________
Bernard Pottier                Laboratoire d'Informatique de Brest *  Projet ArMen
Universite de Bretagne Occidentale, 6 avenue Le Gorgeu, BP 809, Brest 29285 FRANCE
tel (33) 98 01 62 15.  e-mail pottier@univ-brest.fr   fax (33) 98 01 61 31
ftp ftp.univ-brest.fr pub/dept_info/ArMen/publi



Article: 478
Subject: ASIC emulation (Quickturn, etc.)
From: linder@ERC.MsState.Edu (Dan Linder)
Date: 30 Nov 94 11:12:10
Links: << >>  << T >>  << A >>
We're looking into ASIC emulation of the Quickturn variety and are
interested in experiences with Quickturn or any other FPGA-based emulation
systems.  Can you just drop a design on it and start running test vectors
through, or do you still have do some FPGA-like hardware design?  Does it
scale well to large emulations, say of a complete CPU or even multiple
chips?  We hear that the emulation runs 100 times slower than actual
hardware (which seems a little slow).  Are the FPGAs really that much
slower individually or is it a problem with their combination into a larger
system?

Any insights, experiences and/or references to articles describing
experiences would be greatly appreciated.  I will summarize responses for
the net.  Thanks again.

**********************************************************************
  NSF Engineering Research Center for Computational Field Simulation
**********************************************************************
Daniel H. Linder                               linder@erc.msstate.edu
NSF Engineering Research Center for CFS        (601) 325-2057
P.O. Box 6176                                  fax:  (601) 325-7692
Miss. State, MS  39762
**********************************************************************


Article: 479
Subject: Re: ASIC emulation (Quickturn, etc.)
From: mbutts@netcom.com (Mike Butts)
Date: Wed, 30 Nov 1994 19:39:37 GMT
Links: << >>  << T >>  << A >>
linder@ERC.MsState.Edu (Dan Linder) writes:

> We're looking into ASIC emulation of the Quickturn variety and are
> interested in experiences with Quickturn or any other FPGA-based emulation
> systems.  
>
> Can you just drop a design on it and start running test vectors
> through, or do you still have do some FPGA-like hardware design? 

Yes you can.  All the FPGA-specific details are completely contained
within the design compiler, which does the technology mapping from the
source netlist and libraries into the FPGAs.  The emulation user sees
the design elements, netnames, etc. in the design's terms.  After running
your vectors, or even without vectors, you can go directly in-circuit.
 
> Does it scale well to large emulations, say of a complete CPU or even 
> multiple chips?  

It scales very well to large emulations.  Intel, Sun, and many other
major developers are emulating entire CPU designs, at 2 million gates and more.
Quickturn's System Emulator M3000 has a 3 million gate capacity, with 
provisions for multi-M3000 systems that allow over 10 million gate emulations
off the shelf.  Most CPU developers and many ASSP and ASIC projects now use
Quickturn emulators to run OSs and applications before tapeout.

> We hear that the emulation runs 100 times slower than actual hardware 
> (which seems a little slow).  Are the FPGAs really that much slower 
> individually or is it a problem with their combination into a larger system?

The programmable interconnect inside and between FPGAs does take more time 
than real metal and wires, because of RC delays in pass transistors and many 
more chip-crossings.  100X slowdown is an upper bound in our experience.  
Most emulations run from 1 to 8 MHz.  That's 3 to 5 orders of magnitude faster 
than cycle-based simulators, which is the difference between running lots of 
real code and just doing vectors or one OS boot.  Multi-million-gate CPU 
emulations are slower than 200K gate ASIC emulations, but the CPU projects find
the speed is plenty for what they do so it all works out.  ASICs typically run 
at multi-MHz in current-generation emulators, and there are many techniques 
for successfully matching the target system's speed to the emulator.

> Any insights, experiences and/or references to articles describing
> experiences would be greatly appreciated.  I will summarize responses for
> the net.  Thanks again.
 
A detailed and quantitative article written by a user is called "Logic Design 
Aids Design Process", by Jim Gateley of Sun, in the July 1994 issue of 
ASIC & EDA.  It's an account of the MicroSPARC II project's experiences with 
the Quickturn Enterprise (previous generation) logic emulator on a 200K 
gate 32-bit SPARC CPU.

"During the 25 days prior to tapeout, the emulated processor and testbed
system successfully executed power-on self tests and open boot PROM, booted
single- and multi-user Solaris, Open Windows, and Open Windows applications.
Altogether, emulation logged 15 bugs and enhancements against MicroSPARC II, 
PROM, and the kernel before tapeout. First silicon was very clean.  
MicroSPARC II shipped three months early."

           --Mike Butts, Emulation Architect, 
                         Quickturn Design Systems (mbutts@qcktrn.com)

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



Article: 480
Subject: Re: ASIC emulation (Quickturn, etc.)
From: dej@eecg.toronto.edu (David Jones)
Date: 30 Nov 94 22:03:31 GMT
Links: << >>  << T >>  << A >>
In article <mbuttsD03IM1.G8C@netcom.com>, Mike Butts <mbutts@netcom.com> wrote:
>real code and just doing vectors or one OS boot.  Multi-million-gate CPU 
>emulations are slower than 200K gate ASIC emulations, but the CPU projects find
>the speed is plenty for what they do so it all works out.  ASICs typically run 

Interesting question: What is the slowest "acceptable" speed for logic
emulation of a CPU?

In particular, would 1/256 full-speed be acceptable?



Article: 481
Subject: Re: ASIC emulation (Quickturn, etc.)
From: rwieler@ee.umanitoba.ca (wieler)
Date: 30 Nov 1994 23:38:21 GMT
Links: << >>  << T >>  << A >>


In article 94Nov30111210@gemini.ERC.MsState.Edu, linder@ERC.MsState.Edu (Dan Linder) writes:
>We're looking into ASIC emulation of the Quickturn variety and are
>interested in experiences with Quickturn or any other FPGA-based emulation
>systems.  Can you just drop a design on it and start running test vectors
>through, or do you still have do some FPGA-like hardware design?  Does it
>scale well to large emulations, say of a complete CPU or even multiple
>chips?  We hear that the emulation runs 100 times slower than actual
>hardware (which seems a little slow).  Are the FPGAs really that much
>slower individually or is it a problem with their combination into a larger
>system?

No experiences except on our homegrown system, however you should not be
surprised at system level, or large emulutions running 100 times slower.
Remember that CPU bus speeds (internal) are now running at 100 +MHz, think
of the wire length busses have to run through on a board that will fit
such a design for emulation.  There is no way you will get anywhere near
that speed.  However a drop in speed by only 100 is small potatoes, when
you think of the drop in speed when simulating.  Good luck.

Richard 
Dept of Electrical and Computer Eng.
University of Manitoba


Article: 482
Subject: White Mountain's "DSP Summit" on the WWW
From: dspnet!dspadmin@@uunet.uu.net (DSPnet Administrator)
Date: 1 Dec 1994 00:05:43 GMT
Links: << >>  << T >>  << A >>
White Mountain's "DSP Summit" Fall Newsletter can now be accessed on the
world wide web via DSPnet. 
This is the second issue of this Newsletter to appear on the WWW.
 
The issue features the following information:

- C5x Development System
- DSP hits the Internet
- JTAG Emulation Principles
- PC vs. Sun Environment

To access this newsletter with a WWW browser go to URL:  http://www.dspnet.com
Access with a common terminal:  telnet dspnet.com     (and login as lynx)
DSPnet is free (you just have to register once when you login for the 1st time)



Article: 483
Subject: Re: Bit Serial ?
From: ep520mi@pts.mot.com (MARK INDOVINA Xxxxx Ppppp)
Date: Thu, 1 Dec 1994 02:10:12 GMT
Links: << >>  << T >>  << A >>
I believe one of the Mistral (sp?) tools that are part of Mentor
Graphics DSP Station (Mistral I or Mistral II) can decompose an
algorithm into a bit-serial representation. The foundation of this
tool set is work that was done in the Phillips Research Labs in
Europe. Once implemented the design can be written out as RTL VHDL
or Verilog HDL.

Regards,
Mark

-- 
/* Mark A. Indovina, Principal Staff Engineer   mark_indovina@pts.mot.com */
/* Motorola        Applied Research, Advanced IC Technology Laboratory    */
/* Mail Stop 63, 1500 Gateway Boulevard, Boynton Beach, FL 33436-8292 USA */
/* phone: 1-407-364-2379, fax: 1-407-364-3904     ...just speaking for me */


Article: 484
Subject: Altera VHDL Option Performance ?
From: dalmau@xerox.com (John Dalmau)
Date: 1 Dec 1994 19:14:21 GMT
Links: << >>  << T >>  << A >>




Article: 485
Subject: Altera VHDL Opt..Second Try!
From: dalmau@xerox.com (John Dalmau)
Date: 1 Dec 1994 19:28:05 GMT
Links: << >>  << T >>  << A >>

Sorry about the blank note. Here is another try!
We recently benchmarked Altera's VHDL option to Synopsys VHDL Synthesis and obtained mixed results. Has anyone performed a similar benchmark. We are mainly looking at how well Altera's VHDL option does in timing and area results when compared to Synopsys synthesis approach. Any comments would be appreciated. :) Thanks. You may e-mail to me at:  JDalmau.es_ae@xerox.com




Article: 486
Subject: Re: Altera VHDL Opt..Second Try!
From: ventti@fincitec.fi (Veli-Matti Karppinen)
Date: Fri, 2 Dec 1994 08:48:10 GMT
Links: << >>  << T >>  << A >>
In article <3bl845$a5e@vine.cp10.es.xerox.com> dalmau@xerox.com (John Dalmau) writes:

>We recently benchmarked Altera's VHDL option to Synopsys VHDL Synthesis and obtained mixed results. Has anyone performed a similar benchmark. We are mainly looking at how well Altera's VHDL option does in timing and area results when compared to Synopsys
>synthesis approach. Any comments would be appreciated. :) Thanks. You may e-mail to me at:  JDalmau.es_ae@xerox.com


Based on our trials with Altera VHDL-option using codes initially written for 
Synopsys, my opinion is that you should go the Synopsys route. The constraints 
for the syntax place quite a lot of restrictions compared to the subset, which 
is currently supported by Synopsys. This is purely from the technical point of 
view, certainly there is on other hand a difference between the price tags...

Anyway, I'm eagerly waiting for the promised enhancements in Altera VHDL 
support, but .... those are not yet here.

Regards,

Veli-Matti Karppinen
---------------------------------------------------------------
Veli-Matti Karppinen                Fincitec Oy
P.B. 11, FIN-94601 Kemi             Tel. +358 698 221 490
Finland                             Fax. +358 698 221 561
        
" Once you have flown, you will walk your eyes turned towards
  the sky, for there you've been and there you long to return "
                                     -- da Vinci


Article: 487
Subject: FPGA boards available?
From: seamang@westminster.ac.uk (Graham Seaman)
Date: Fri, 2 Dec 1994 14:55:29 GMT
Links: << >>  << T >>  << A >>
Hi everyone,

Like lots of other people we (we=just two people for now)
are interested in looking at FPGA-based computing (for
image related work) - and we've just got a little money
to spend on it. We have Powerview running on Sparcs as
our development tool, and would ideally like to work
with fairly fine-grained FPGAs.
A lot of people that have published work in this area seem to
have done something similar - developed a board with around
4-6 FPGAs, a programmable cross-bar switch, and some K of RAM.
Is anyone prepared to sell one of these boards to us?
The obvious question is, why don't we too produce our own?
Unfortunately, we have a deadline to spend our money by -
and its too short to do that (added to which, this is a CS
department, not EE, so we don't have any arrangements for
board manufacture).
Any suggestions gratefully received! (I guess this may be
a common problem so I'll summarize if I get email replies)

Graham
-- 
--------------------------------------------------------------------
Graham Seaman, School of Computer Science, 
University of Westminster, 115 New Cavendish St.  London W1M 8JS 
email:  seamang@wmin.ac.uk www: http://www.wmin.ac.uk/~seamang


Article: 488
Subject: FPGA '95 Symposium Advance Program
From: jayar@eecg.toronto.edu (Jonathan Rose)
Date: 2 Dec 94 20:27:59 GMT
Links: << >>  << T >>  << A >>
			FPGA `95 Advance Program
			------------------------

1995 ACM Third International Symposium on Field-Programmable Gate Arrays

			February 12-14, 1995
		    Marriott Hotel, Monterey, CA, USA

Note: The Symposium location is now Monterey.

Sponsored by ACM SIGDA, and Actel Corp., Altera Corp. and Xilinx, Inc.


Field-Programmable Gate Arrays (FPGAs) have revolutionized ASIC design by 
providing fast turnaround and negligible overhead cost. The challenge in 
FPGA research is to improve the speed and density of the devices, and find 
new CAD synthesis algorithms that make effective use of the new architectures. 
The objective of this symposium is to bring together people who are working 
in the many areas of research that are necessary to make a complete FPGA and 
high-capacity PLDs. 

The technical program consists of papers concerning FPGAs and High-Capacity 
PLD device architecture, Computer-Aided Design of these devices, architecture 
of multi-FPGA systems and CAD tools associated with these systems. In 
addition, there are several papers concerning applications of programmable 
logic.
The Symposium will be of interest to those developing FPGA architectures, both 
at the chip and board level, and those developing CAD algorithms for FPGAs. 
The Symposium is not of direct interest to immediate users of FPGAs.

General Chair: Pak K. Chan, UC Santa Cruz
Program Chair: Jonathan Rose, University of Toronto

Program Committee

Duncan Buell, SRC
Pak K. Chan, UCSC
Jason Cong, UCLA
Carl Ebeling, U. Washington
Ewald Detjens, Exemplar
Frederic Furtek, Atmel
Dwight Hill, Synopsys
Sinan Kaptanoglu, Actel
John McCollum, Actel
Jonathan Rose, U. Toronto
Richard Rudell, Synopsys
Rob Rutenbar, CMU
Takayasu Sakurai, Toshiba
Martine Schlag, UCSC
Tim Southgate, Altera
Steve Trimberger, Xilinx

Program
-------

Sunday February 12, 1995

6:00pm	Registration

7:00pm	Welcoming Reception, Marriott Hotel, Monterey

Monday February 13, 1995

8:20am	Opening Remarks

Session 1: General Purpose Architecture 

Chair: Tim Southgate, Altera

8:30am	On Designing ULM-Based FPGA Logic 
        Modules, S. Thakur, D.F. Wong, U. of Texas

8:50am	Using Architectural "Families" to Increase FPGA 
        Speed and Density, V. Betz, J. Rose, U.  Toronto

9:10am	Design of FPGAs with Array I/O for Field 
        Programmable MCM, J. Darnauer, J. Ramirez, 
        W. W-M. Dai, U. of Cal. Santa Cruz

Posters: General Purpose Architecture

9:30-10:30am Coffee & Posters	

Session 2: Field-Programmable Systems

Chair:	Carl Ebeling, University of Washington

10:30am	TIERS: Topology Independent Pipelined Routing 
        and Scheduling for Virtual Wire Compilation, 
        C. Selvide, A. Agarwal, M. Dahl, J. Babb, Virtual 
        Machine Works, MA.

10:50am	Logic Partition Orderings for Multi-FPGA 
        Systems, S. Hauck, G. Borriello, U. Wash.

11:10am	An FPGA-Based Reconfigurable Co-processor 
        Board Utilizing a Mathematics of Arrays, H. 
        Pottinger, W. Eatherton, J. Kelly, T. Schiefelbein, 
        U. of Missouri - Rolla

Posters: Field-Programmable Systems 11:30-12

LUNCH 12:00 - 1:30

Session 3: Applications I

Chair: Pak K. Chan, UCSC

1:30pm	High-Energy Physics on DECPeRLE-1 
        Programmable Active Memory, L. Moll, 
        J. Vuillemin, P. Boucard, Digital Equip. Corp, 
        Paris Res. Lab, France

1:50pm	HGA: A Hardware-Based Genetic Algorithm, 
        S. D. Scott, A. Samal, S. Seth, Wash. Univ, 
        U. of Nebraska-Lincoln

2:10pm	The U.S.C. Multiprocessor Testbed: A Rapid 
        Prototyping Engine, K. Oner, L. Barroso, 
        S. Iman, J. Jeong, K. Ramamurthy, M. Dubois, 
        U.  Southern California

Posters: Applications

2:30-3:30pm Coffee & Posters

Session 4: Logic Synthesis

Chair:	Richard Rudell, Synopsys

3:30pm	Simultaneous Depth and Area Minimization in 
        LUT-Based FPGA Mapping, J. Cong, 
        Y-Y. Hwang, U. of California, L.A.

3:50pm	Synthesis of Signal Processing Structured 
        Datapaths for FPGAs Supporting RAMs and 
        Busses, B. Haroun, B. Sajjadi, Concordia 
        University.

4:10pm	On Nominal Delay Minimization in LUT-Based 
        FPGA Technology Mapping, J. Cong, Y. Ding, 
        UCLA.

Posters: Logic Synthesis and Co-Design

4:30-6:00pm Free time/Posters

Dinner 6:00-7:30pm



7:30-9:00pm  PANEL

The Architecture/Software Boundary:

Motherhood & Lies.

The most crucial element in the creation of an FPGA is the 
interaction between the device architecture and the software 
tools that map circuits into the device. The architect should 
determine the ability of the placement and routing software, 
for example to:

i.  Deal with routing architecture's overall structure 
    (such as symmetric vs. asymmetric; hierarchical vs. 
    flat, segmented routing etc.)

ii. Handle special purpose connections, such as carry 
    chains, local interconnect or hard-wired connections.

iii.Route typical circuits with the fixed total amount of 
    interconnect. For example, should different-sized 
    parts be given different quantities of routing?

Similarly the architecture should be able to deal with the 
capability of the logic synthesis tools to handle:

i.  The structure and function of the logic block.

ii. Special logic block features such as adder logic, clock 
    qualifiers and logic sharing capability.

iii.The effect of the synthesis on the routability of the 
    synthesized netlist.

Although FPGA vendors and academic architects will 
immediately agree with that this interaction is essential, and 
is indeed a motherhood issue, it is actually rare that these 
interactions are enforced. Similarly, synthesis vendors (and 
University CAD researchers) may claim to produce FPGA 
architecture-specific algorithms but the reality is otherwise. 
What makes it so difficult?

Is interaction really important, or will the effects of poor 
interaction be swallowed by the next generation IC process 
advance? Perhaps some very clever interactions can produce 
major density and speed gains FPGA devices.

If interaction is difficult to enforce for general-purpose 
FPGA architectures, will it be possible to create a next 
generation of special-purpose architectures?

This panel will explore these issues by bringing together 
several people from the FPGA vendor community, the 
FPGA user community, synthesis vendors and researchers.

Tuesday February 14, 1995

Session 5: Architecture of Special-Purpose Structures

Chair:	Steve Trimberger, Xilinx

8:30am	Revisiting the Cascade Circuit in Logic Cells of 
        Lookup Table Based FPGAs, N-S. Woo, AT&T 
        Bell Labs, N.J.

8:50am	Architecture of Centralized Field-Configurable 
        Memory, S.J.E. Wilton, J. Rose, Z.G. Vranesic, 
        U.  Toronto

9:10am	A Field-Programmable Mixed-Analog-Digital 
        Array, P. Chow, P. Chow, P.G. Gulak, 
        U.  Toronto


Posters: Special-Purpose Architecture

9:30-10:30am Coffee & Posters	

Session 6: Placement, Routing & Testing

Chair:	Jason Cong, UCLA

10:30am	PathFinder: A Negotiation-Based Performance-
        Driven Router for FPGAs, L.E. McMurchie, 
        C. Ebeling, U. Washington

10:50am	Applications of Slack Neighborhood Graphs to 
        Timing Driven Optimization Problems In 
        FPGAs, A. Mathur, K.C. Chen, C.L. Liu, 
        U. Illinois, Fujitsu America, San Jose

11:10am	Testing of Uncustomized Segmented Channel 
        Field Programmable Gate Arrays, T. Liu, 
        W.K. Huang, F. Lombardi, Texas A&M University

Posters: Routing and Fault-Tolerance 11:30-12 

LUNCH 12:00 - 1:30

Session 7: Multi-FPGA Partitioning

Chair:	Martine Schlag, UCSC

1:30pm	Spectral-Based Multi-Way FPGA Partitioning, 
        P.K. Chan, M.D.F. Schlag, J.Y. Zien, U. of 
        California, Santa Cruz

1:50pm	Multi-Way System Partitioning into Single or 
        Multiple Type FPGAs, D. J-H. Huang, A.B. 
        Kahng, UCLA

2:10pm	Multiple FPGA Partitioning with Performance 
        Optimization, K. Roy-Neogi, C. Sechen, U. 
        Washington

2:30-3:30pm Coffee & Posters

Session 8: Applications and Bit-Serial Synthesis

Chair:	Sinan Kaptanoglu, Actel

3:30pm	Techniques for FPGA Implementation of Video 
        Compression Systems, B. Schoner, J. Villasenor, 
        S. Molloy, R. Jain, UCLA.

3:50pm	An SBus Monitor Board, H.A. Xie, K.E. 
        Forward, K.M. Adams, D. Leask, U. Melbourne, 
        Australia

4:10pm	High-Level Bit-Serial Datapath Synthesis for 
        Multi-FPGA Systems, T. Isshiki, W. W-M. Dai, 
        U. California, Santa Cruz

Posters: Applications 4:30-5:00


		    FPGA `95 REGISTRATION
		    ---------------------

The Symposium registration fee includes a copy of the symposium proceedings, 
a reception on Sunday evening, February 12, coffee breaks, continental breakfast 
on the first day, lunch on both days, and dinner Monday evening, February 13.

First Name:___________________________________________
Last Name:____________________________________________
Company/Institution___________________________________
Address:______________________________________________

City:___________________State:_____________
Postal Code:_______________Country:____________

Email:________________________________________
Phone:_______________________Fax:_______________________

Circle Fee	Before January 25, 1995 	After January 25, 1995 ACM Member #____________

ACM/SIGDA Member 	US $320 			US $390

*Non-Member	        US $417				US $487

*If you are not an ACM/SIGDA member we are giving you the opportunity to 
join by paying your first year's dues out of your conference non-member 
registration fee -- a US$97 value. Forms will be available at on-site 
registration.

Guest Reception Tickets #Tickets______x US $15 ______
Guest Banquet Tickets #Tickets______x US $40 ______

Total Fees:____________________(Make checks payable to ACM/FPGA'95)
Payment Form (Circle Once)

AMEX 	MASTERCARD	 VISA	 CHECK

Credit Card#:_____________________
Exp. Date:________________________
Signature:________________________________________

Send Registration with payment to:

	FPGA `95, Colleen Matteis, 553 Monroe St., Santa Clara, CA. 95050, USA. 
	Phone: +1(408)296-6883 Fax: +1(408)296-5452.

For registration information contact Colleen Matteis, 
e-mail: sigda@nextwave.com. Cancellation must be in writing, and 
received by Colleen Matteis before January 24,1995.

		Hotel Information
		-----------------

The symposium will be held at the Monterey Marriott, 350 
Calle Principal, Monterey, CA 93940, USA. The phone 
number for room reservations is (408) 649-4234. 
Reservations must be made directly with the Hotel before 
January 20, 1995. Identify yourself with the group 
Association for Computing Machinery FPGA `95 
Symposium to receive the special Symposium rates,which
are $110 for single or double occupancy; parking is $10 per day.
Check-in time is 3pm.

Directions to Hotel: From San Jose (a 1.5 hour trip), take 
HWY 101 South to HWY 156 west to HWY 1 South. On 
HWY 1 South, take the first exit in the city of Monterey 
(labelled Del Monte Ave.). Continue on Del Monte Avenue 
until the tenth traffic light. Stay in the left lane, and the 
hotel will be on the left. The hotel is the tallest building in 
the City of Monterey.

You can also fly directly to the Monterey Airport, which 
handles United, American and other air lines with at least 
8 flights per day.


Article: 489
Subject: Re: XC3090 PERFROMANCE...
From: dennison@calspan.com (Ray Dennison)
Date: Fri, 2 Dec 1994 21:51:23 GMT
Links: << >>  << T >>  << A >>
In <3bfpbu$tdu@hearst.cac.psu.edu> SANJAYB@ECLX.PSU.EDU (Sanjay Balasubramanian) writes:

>Hi,
>	We are currently using the XC3090PG175 to implement a circit which
>demands a speed of 25MHz (40ns). However any attempt to reach a speed higher
>than 12ns has proved futile with the XC3090. (We are only using 38 CLBs and
>abot 70 I/O pads, 150 speed grade). Are there existing designs which run at 
>higher speeds on the XC3090 and if so any pointers to increase the performance
>will be greatly appreciated.

>Please e-mail us at:
>s1b@eclu.psu.edu
>Center for Electronic Design, Communication and Computing
>University Park.

>Thanks in advance,
>Sanjay B.

>	
You don't mention what sort of circuit you are trying to implement. I have some limited experience with the part you are using and perhaps some of this may apply.

If you are trying to do stuff that requires wide gating functions - multi-bit counters, adders, etc. then the limited number of inputs per CLB really becomes 
problem with the XILINX architecture. Several CLBs must be used serially to get the desired function and therefore much speed is lost.

I have also found that using the library functions is very simple but almost always results in a slow design. It seems that you really need to get in and work at the CLB level. The XACT tool seems to do a horrible job at CLB
placement considering how long it takes to do it. Perhaps it is designed
to optomize for resource usage rather than speed. (or perhaps I just don't
know how to use it.) Anyways, I found that I could get tremendous speed increases by doing my own CLB placement and optomizing critical signal interconnection through the direct interconnects. 

I was able to achieve a 20-bit 20Mhz counter on a 125Mhz part using this approach, but it took a lot of work. A bonus in doing your own placement
is that the compiler runs much faster.

Has anyone else had similar experience or can suggest ways to use the compiler
to optimize more for speed?


Article: 490
Subject: Any Good HDL Tools for the PC?
From: morph@io.org (Ryan Raz)
Date: 2 Dec 1994 19:22:21 -0500
Links: << >>  << T >>  << A >>
We are currently working on a large design including digital filters,
shift registers, SRAM's, VRAM's, etc. Also we will be using FPGA's
to handle timing, control and ALU functions.

We are looking for CAD tools for overall design description and simulation
and FPGA synthesis. So far we have looked at Data I/O's Synario,
Viewlogic's Pro Series, Exemplar Logic and the Xilinx development tools.

Are there any comments on these systems or on alternatives?

----------------------------------------------------------------- 
 Ryan S. Raz     
 Morphometrix, 120 Adelaide St. E., Unit 2, 
 Toronto, Ontario, Canada M5C 1K9
 Tel: (416)361-6239   Fax: (416)361-3162   Email: morph@io.org
-----------------------------------------------------------------


Article: 491
Subject: need xnf files for Partitioning93 benchmark circuits
From: Mohammed Khalid <khalid@eecg.toronto.edu>
Date: Mon, 5 Dec 1994 18:05:37 GMT
Links: << >>  << T >>  << A >>

I need xnf files for  Partitioning93 benchmark circuits. The xnf files
currently available are in LCANET Version 2, which are not acceptable to
the latest XACT tools (version 5.0). I need xnf files in LCANET Version
4 or 5. I tried to use 'xnfcvt' program, but that translates only from
higher to lower version, e.g. from 5 or 4 to 2.

Any help will be greatly appreciated.

Khalid



Article: 492
Subject: New Low Cost IC Design Software L-EDIT SE (PC)
From: jjcain@indirect.com (John Cain)
Date: Tue, 6 Dec 1994 05:48:49 GMT
Links: << >>  << T >>  << A >>
"Low Cost IC Design Software for the PC"


There is a new low cost PC version of L-EDIT "the student edition" for
the layout and evaluation of custom CMOS IC designs.


Book Review - PHY. DESIGN OF CMOS ICs USING L-EDIT (tm) by Uyemura

A new book "PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L-EDIT
(1995)" by John P. Uyemura has been published by PWS Publishing Company
(Boston, MA). This $54.95 book (ISBN 0-534-94326-8) includes the L-EDIT
student edition which provides students and industry professionals a
complete tool to learn the art of CMOS integrated circuit design and
layout on a standard IBM Compatible PC.

For those in the know, L-EDIT is the best kept secret in the IC
industry. L-EDIT is the work of industry legend John Tanner and the
gurus at Tanner Research. L-EDIT provides a complete VLSI IC Design
software environment for a few thousand dollars including custom
design, autorouting, DRC, Extraction, LVS and compatible libraries.
The new L-EDIT student edition together with Uyemura's book extends
Tanner's innovation providing an outstanding tool to learn IC design.

"PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L-EDIT" is a well
focused and integrated book that teaches elementary digital CMOS design
and layout. This 209 page book includes the necessary information in a
well organized format, for the engineering student or self study
professional with no IC background, to learn elementary IC design. This
book condenses the complexity of IC physics, concepts, fabrication
processes, design rules, physical implementation and modeling equations
into the essentials to understand IC design and layout.

The book then proceeds to apply these elements using L-EDIT to create
working designs. The book takes the student through the design steps
and provides the KEY design data, coefficients, and setups at the right
learning point sparing the student the typical confusion from
information overload.  The book is well integrated with the L-EDIT
student edition starting with program setup, and proceeding with cell
layout, design rules, DRC, modeling, extraction, and spice modeling.
The book is particularly good at linking basic gates and layout style.
It also details the more esoteric aspects of layer setups for
extraction and DRC and provides the necessary details for spice
modeling.  The book also includes a first introduction to the varied
aspects of digital CMOS design including devices, gates, logic types,
and CMOS processes as well as more complex layout design.

For the price, the book together with the PC compatible L-EDIT student
edition is a bargain including full IC layout, multi-cell hierarchy
design, comprehensive design rule check, spice 2/3 compatible IC layout
extraction, cross-sectional viewer and technology compatible setups for
standard CMOS processes. The user interface and features are the same
as the professional level L-EDIT program except for a limit on database
size ( suited for up to a "Mosis Tiny"-2.2 mm x 2.2 mm ) and the use of
the Tanner TDB format for saving work files.

The professional level L-EDIT program is needed to convert from the
Tanner TDB file format to the industry standard CIF or GDSII IC mask
generation file format. Cell designs created with student edition are
fully compatible with the professional version making the student
program ideal for independent work on small designs in industrial
settings with a standard PC.

To enhance the use of this book and L-EDIT it is recommended that you
obtain a copy of the L-EDIT demo disk (V5.0) and use the file
scmosmin.tdb as an starting point for an operational cell. While the
book includes examples of CMOS designs, it only provides limited L-EDIT
TDB file examples. Scmosmin.tdb provides some standard cell gate
examples and can be used as a template to get the novice student
started with designs that work.

The student will need to obtain a copy of Spice to simulate their
extracted cell designs. Check out the EDN BBS (617-558 4241) Spice
files 29103-5 and down load Howard LeFevre's excellent Berkeley Spice
3F3 (386) Dos shareware.

I suspect that most who read this book will become hooked on the wonder
of CMOS IC design and will thirst for more. A good added text that
provides a more comprehensive treatment of CMOS design and takes you to
the system level is "Principles of CMOS VLSI Design 2e" by Weste &
Eshraghian.

In conclusion "PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L-
EDIT(tm)" is an outstanding text with companion software for anyone
wanting to learn CMOS IC design and layout. John Uyemura has distilled
the essentials of CMOS design into an easily useable form that will
become the standard for training future CMOS designers.

Highly recommended.




John Cain
Power Processing, Inc.





Article: 493
Subject: WWW sites for Product Info
From: cdodge@hermes.zkm.de (Chris Dodge)
Date: 6 Dec 1994 20:19:50 GMT
Links: << >>  << T >>  << A >>
Hello,

Sorry for the newbie question, but does anyone know if any FPGA manufactures
operate a WWW site for product information and literature? (yes, this does
soud like a good idea...)

Thanks,

Chris


Article: 494
Subject: Any benchmark for FCMs?.
From: moran@die.upm.es (Javier Moran Carrera)
Date: Wed, 7 Dec 1994 08:31:58 GMT
Links: << >>  << T >>  << A >>
Hello:

We have designed and built a FPGA-based Computing Machine. Actually, we
do not have any particular application, but just a set of them, and we want
to analyze our architecture and compare it against other approaches.
In the literature, there are certain applications of FCMs described, but 
quite usually, they are only overviews.

Our question is:

Is there any set of benchmarks for FCMs to compare different 
architectures and software tools?. If so, where it is?

Otherwise, we think it is interesting to open a discussion to set common
benchmarks for FCMs. The benchmarks themselves, the format to express
them (VHDL, verilog, netlists...), and some other technical issues (e.g.
how to compare a system with 256 FPGAs against one with 4) are not trivial
problems. Any ideas?


Regards,

Javier Moran
Electronic Engineering Department
ETS Telecomunicacion.
Technical University of Madrid.

Address: Ciudad Universitaria s/n.
         Madrid 28040. Spain.

email: moran@die.upm.es




Article: 495
Subject: Re: L-Edit and Benchmarks
From: sc@vcc.com (Steve Casselman)
Date: Wed, 7 Dec 1994 21:03:19 GMT
Links: << >>  << T >>  << A >>
> Subject: New Low Cost IC Design Software L-EDIT SE (PC)
> 
> "Low Cost IC Design Software for the PC"
> For those in the know, L-EDIT is the best kept secret in the IC
> industry. L-EDIT is the work of industry legend John Tanner and the
> gurus at Tanner Research. L-EDIT provides a complete VLSI IC Design
> 

The L-EDIT package is great. I had the chance to meet John Tanner and his gang 
since they live quite close to me. I used their software to design a
full custom crosspoint switch that could hold two configurations at a time,
you could use one while loading the other and then flip between them. I had
never done a full custom design before and I found it very easy to
put together a my own chip. I here Tanner is getting a low cost schematic
tool that will support all sorts of FPGAs.


> Highly recommended.

ditto!

About benchmarks.
> 
> Is there any set of benchmarks for FCMs to compare different 
> architectures and software tools?. If so, where it is?

There are no benchmarks for reconfigurable computers. I think we
should and try to use existing supercomputer benchmarks. We may
deside to do fixed point instead of floating but I think if we
want to know our relitive preformance it should be relitive to
*some* existing standard. Many of the supercomputer standards are
based on fundemental computing bottlenecks and real world problems.

> 
> Otherwise, we think it is interesting to open a discussion to set common
> benchmarks for FCMs. The benchmarks themselves, the format to express
> them (VHDL, verilog, netlists...), and some other technical issues (e.g.
> how to compare a system with 256 FPGAs against one with 4) are not trivial
> problems. Any ideas?
> 
> 

I think the format for any benchmarks should be either 

1) pen and paper or
2) C code

The idea here is to specify the benchmark at the highest level.
In the pen and paper approach the benchmark is pure algorithm.
Consisting of a mathematical description of the input data, the
algorithm and output data. The C code approach gives the implementor
a real example of the behavior of an algorithm. A C benchmark allows
the designer to make hardware/software tradeoffs -- if their using
a big board they can put the whole algorithm in hardware if they
are using a small board they can cut up the program and divide and 
conqure. I'm against VHDL or netlists because this would make
the benchmarks look more like PREP, we would only find out 
how many gates can a system load at one time. It might be slanted 
toward fine grained architectures or look-up style FPGAs. 

If we talk about benchmarks let us go in the direction of benchmarks
that can be related to by people outside our foucs as well as inside.


Steve Casselman


Article: 496
Subject: Re: WWW sites for Product Info
From: Delayne Plesko <drp@microplex.com>
Date: 7 Dec 1994 23:10:58 GMT
Links: << >>  << T >>  << A >>
cdodge@hermes.zkm.de (Chris Dodge) wrote:
>
> Hello,
> 
> Sorry for the newbie question, but does anyone know if any FPGA manufactures
> operate a WWW site for product information and literature? (yes, this does
> soud like a good idea...)
> 
> Thanks,
> 
> Chris

Xilinx has one:

http://www.xilinx.com/

It doesn't have much information, but it is just at the beginning
stages.

Delayne


Article: 497
Subject: test
From: keith@tommy.doctord.com (Keith Vertrees)
Date: 8 Dec 1994 02:01:27 GMT
Links: << >>  << T >>  << A >>
Sorry this is a test. Don't flame me.


Article: 498
Subject: Re: L-Edit and Benchmarks
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 8 Dec 1994 15:16:32 -0700
Links: << >>  << T >>  << A >>

|> 
|> I think the format for any benchmarks should be either 
|> 
|> 1) pen and paper or
|> 2) C code
|> 
|> The idea here is to specify the benchmark at the highest level.
|> In the pen and paper approach the benchmark is pure algorithm.
|> Consisting of a mathematical description of the input data, the
|> algorithm and output data. The C code approach gives the implementor
|> a real example of the behavior of an algorithm. 

Why C-code? C-code seems like a poor choice as it only supports 
sequential semantics. Thus any algorithm implemented in C will
demonstrated *sequential* behavior. However, the goal is to implement 
hardware that is highly concurrent. I don't see where C will be
helpful in this case.

|> A C benchmark allows
|> the designer to make hardware/software tradeoffs -- if their using
|> a big board they can put the whole algorithm in hardware if they
|> are using a small board they can cut up the program and divide and 
|> conqure. 

I think that C falls flat when it comes to hardware/software tradeoffs.
Again, a C-implementation of an algorithm and a hardware implementation
of an algorithm will likely be quite different for the reasons that
I expressed above. Using C will only complicate the design-space
search for mixed hardware-software solutions.











-- 
        Brad L. Hutchings (801) 378-2667          Assistant Professor
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
                       Reconfigurable Logic Laboratory



Article: 499
Subject: driving PCI
From: Doug Hahn <hahn@ca.merl.com>
Date: 9 Dec 1994 17:43:37 GMT
Links: << >>  << T >>  << A >>
I was wondering if anyone has any experience driving a PCI
bus from an XC4000 device.  PCI has specific I/V characteristics
which need to be met and has anybody have any experience meeting
these criteria (what output driver configuration is needed?).

I was also wondering about the wide edge decoding in the XC4000 
device.  It looks as though the address to be decoded can only
be set at configuration.  Is this true?  How easy is it to modify
the config file to change this address?  Is this information
available?

Thanks




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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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