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
2017JanFebMarApr2017

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 2250

Article: 2250
Subject: Re: Can X30xx Reset itself?
From: Andy Gulliver <andy.gulliver@crossprod.co.uk>
Date: Thu, 09 Nov 1995 10:42:27 -0800
Links: << >>  << T >>  << A >>
It might work, but not reliably.  The problem would be that the logic 
asserting RESET~ would itself be reset, negating RESET~ at a point when 
the rest of the chip might not be fully reset.

A safer scheme would be to latch the output externally, and have that 
signal cleared by whatever initiates the re-programming sequence (this 
all depends, of course, on which mode you use to program the chip!).

Regards

AndyG


Article: 2251
Subject: Re: Can X30xx Reset itself?
From: husby@fnal.gov (Don Husby)
Date: 9 Nov 1995 19:23:11 GMT
Links: << >>  << T >>  << A >>
I wrote:
>I've done this.  You can implement a flip-flop in combinatorial logic and run 
>your system clock to it to provide a full clock cycle's worth of a reset 
>pulse.
>

I got some email responses that indicate that this isn't entirely clear.
Here's an example: 

  It's possible to implement a flip flop using combinatorial CLB logic instead 
of the CLB flip-flop.  The equations would looks something like this:

Q1 = RESET_IN  + Q1*/(CLK*RESET_OUT)

RESET_OUT = Q1*/CLK + RESET_OUT*(CLK+Q1)

Where:
RESET_IN is a synchronous input that changes on the rising edge of CLK.
RESET_OUT drives your external reset pin.

The timing looks something like this

               ______        ______
CLK     ______/      \______/      \__
               __________
RESET_IN _____/         \\____________
                ______________
Q1       ______/             \\_________
                       _______________
RESET_OUT ____________/              \\_____

This circuit should be put in a single CLB to avoid race problems on the
transition of CLK.

(Note that Xilinx recommends against this kind of combinatorial logic, but 
I've used circuits like this before without problems.)



Article: 2252
Subject: Re: JTAG IEEE std 1149.1
From: devb@lys.vnet.net (David Van den Bout)
Date: 9 Nov 1995 14:34:50 -0500
Links: << >>  << T >>  << A >>
In article <47t1qh$o7m@manitou.cse.dnd.ca>,
Paul Brown <pbrown@cse.dnd.ca> wrote:
>	I am looking for info on the JTAG standard, mainly how it is used for
>testing fpga's etc. I would really like an FAQ on this if possible. Can anyone
>point me to the place where this info can be found?
>
>	Thanks in advance for the information.
>
>
>		Paul Brown..... 

I maintain a tutorial on JTAG as one of the chapters in "FPGA Workout II".
You can get it from ftp.vnet.net in directory pub/users/xess/FPGA_Workout_II.
The tutorial uses a simple DOS hypertext format, so you'll have to use a
PC to view it.  We will convert it to HTML before the end of the year and
place it in our Web site http://www.xess.com.


-- 
|| Dave Van den Bout  --  XESS Corp. ||
|| 2608 Sweetgum Dr., Apex, NC 27502 ||
|| (919) 387-0076 FAX:(919) 387-1302 ||
|| devb@xess.com       devb@vnet.net ||


Article: 2253
Subject: Re: Can X30xx Reset itself?
From: peter@xilinx.com (Peter Alfke)
Date: 10 Nov 1995 01:16:49 GMT
Links: << >>  << T >>  << A >>
In article <47riv9$615@news-2.csn.net>, caleb@audiologic.com wrote:

> Is it possible to configure a Xilinx 30xx IOB connected to RESET~
> to successfully reset the chip? If so, how?

Yes, it is possible to connect an output to the active Low RESET pin of
any XC3000 device.
There is no problem during configuration, since all outputs ( except LDC )
are held High with a week pull-up resistor.

When you come to the end of configuration, the output goes active.The
internal reset is being released ( as a configuration option ) either one
CCLK period before or one CCLK period after the outputs go active. See
page 2-29 of the Xilinx data book. The automatic internal reset and the
deliberately applied external RESET ( active Low) have exactly the same
internal effect.
If you drive the RESET input from a combinatorial circuit inside the chip,
you will keep ALL internal flip-flops reset as long as this signal is
active, and there is no exception.

Do not create a "clever" circuit where the output that pulls RESET Low
stops pulling Low as soon as a certain flip-flop has been reset. That is a
glitch-maker that might work, but can fail because the propagation delay
of the RESET signal going to all the many flip-flops can vary by as much
as 25 ns, and you might create an unreliable RESET pulse. 

For more details and ways around such limtations, send me e-mail at
peter@xilinx.com

Peter Alfke, Xilinx Applications


Article: 2254
Subject: Re: BP Micro and CUPL -- a good start?
From: trev@wg.icl.co.uk (Trevor Hall)
Date: 10 Nov 1995 06:56:03 GMT
Links: << >>  << T >>  << A >>

acooney@netcom.com (Alan Cooney) writes :-
> I'm seriously considering a BP1148 or BP1200

We have two BP1200 programmers on site and have been very happy with them.

Cheers,
T.H.



Article: 2255
Subject: Re: Xilinx Configuration Memory Hacking
From: wolf@aur.alcatel.com (William J. Wolf)
Date: 10 Nov 1995 13:31:47 GMT
Links: << >>  << T >>  << A >>
Tim Eccles <Tim@tile.demon.co.uk> writes:
>But would it not be relatively straightforward for Xilinx to add a few bytes
>of non-volatile public key memory (read/write) plus private key memory (write
>only) and implement a small decryption engine.  The configuration data rates
>are so low that a serial arithmetic scheme should be possible.
>
>Even a simple system would give a huge increase in design security.

It seems like this scheme makes a lot of sense for flash based products. 
It does not seem so simple for SRAM based FPGAs.

---
- Bill Wolf, Raleigh NC
- My opinions, NOT my employer's




Article: 2256
Subject: FPGA references and good starting points?
From: ork@mundil.cs.mu.OZ.AU (Brett Christopher WALKER)
Date: Sat, 11 Nov 1995 02:56:18 GMT
Links: << >>  << T >>  << A >>
I'd like to learn about field programmable gate arrays. Can someone
point me to a good reference/FAQ/www page.

thanx

brett
-- 
Brett Walker                         |ork @ mundil.cs.mu.oz.au
5th Year Science/Engineer            |ork @ ecr.mu.oz.au
University of Melbourne		     |brettw @ ocf.berkeley.edu

	$$$$	WWW: http//www.cs.mu.oz.au/~ork	   $$$$
		


Article: 2257
Subject: Re: FPGAs as a substitute for glue logic?
From: seeker@indirect.com (Stan Eker)
Date: 11 Nov 1995 04:52:44 GMT
Links: << >>  << T >>  << A >>
HORSTINK_HMM (iim@ms.philips.nl) wrote:
: Derek Chang (dchang@san-jose.ate.slb.com) wrote:
: : What do you mean the design is different ?

: : You can do anything with an FPGA that discrete ICs
: : can do.

: : Derek

: Yeah! How about speed ?

: Harry

The Xilinx 2K, 3K and 4K parts are slower than molasses, compared to fast
PLDs or discrete logic.  Prop delays of >30nS aren't unusual pad-to-pad, but
they aren't really designed for high-speed multiple level logic.  They're
more fitted for synchronous designs where the logic's clocked stage-to-stage,
and the fast stuff is best done outside.  For price vs. speed, we use the
Altera 7K family for the fast stuff, as it was a good compromise, and the
Xilinx parts are for the slower bulk logic since it's cheaper per gate.

As usual, your mileage may vary.




Article: 2258
Subject: Re: FPGA references and good starting points?
From: devb@lys.vnet.net (David Van den Bout)
Date: 12 Nov 1995 10:50:47 -0500
Links: << >>  << T >>  << A >>
In article <9531513.2334@mulga.cs.mu.OZ.AU>,
Brett Christopher WALKER <ork@mundil.cs.mu.OZ.AU> wrote:
>I'd like to learn about field programmable gate arrays. Can someone
>point me to a good reference/FAQ/www page.
>

We keep a short tutorial at http://www.xess.com.  Also, I think
the University of Idaho keeps an extensive list of FPGA material on their
Web site.  

There's also an engineering library at 
http://epims1.gsfc.nasa.gov/engineering/ee.html that should have links 
concerning FPGAs.


-- 
|| Dave Van den Bout  --  XESS Corp. ||
|| 2608 Sweetgum Dr., Apex, NC 27502 ||
|| (919) 387-0076 FAX:(919) 387-1302 ||
|| devb@xess.com       devb@vnet.net ||


Article: 2259
Subject: Re: Xilinx Configuration Memory Hacking
From: daveb@iinet.net.au (David R. Brooks)
Date: Mon, 13 Nov 1995 00:33:48 GMT
Links: << >>  << T >>  << A >>
Tim Eccles <Tim@tile.demon.co.uk> wrote:

>In article <DHFC7I.9Dy@zoo.toronto.edu>
>           henry@zoo.toronto.edu "Henry Spencer" writes:

><snip>

>>> In fairness, there is one tricky problem:  customers who want to make
>>> their products reverse-engineering-proof.  This is hard to do with the
>>> Xilinx approach, in which the bit stream to program the FPGA *must* come
>>> from an external source and hence is easily tapped.  To handle this in the
>>> context of an open architecture, the chip needs to have either encryption
>>> hardware or on-chip nonvolatile memory, neither of which is trivial.

>But would it not be relatively straightforward for Xilinx to add a few bytes
>of non-volatile public key memory (read/write) plus private key memory (write
>only) and implement a small decryption engine.  The configuration data rates
>are so low that a serial arithmetic scheme should be possible.

>Even a simple system would give a huge increase in design security.

><snip>

  I seem to recall that Xilinx' whole strategy is to use a "plain
vanilla" chip technology, and have their wafers made by several
different subcontractors. (I understand Xilinx do not run a wafer-fab
themselves). Most EPROM and similar technology is proprietary to each
fab; Xilinx would then need a new design for each sub-contractor.

--
Dave



Article: 2260
Subject: Re: AT&T vs. Xilinx
From: skk@CONSYL.cpe.ku.ac.th (Supaket Katchmart)
Date: 13 Nov 1995 17:28:21 GMT
Links: << >>  << T >>  << A >>
George Noten (garyk@svpal.svpal.org) wrote:
: : I prefer the pro-series to the older workview.  It's much more pleasant to
: : use, and works well with Windows 3.1 (but NOT win95).  It doesn't require goofy 
: : pro-sim and view-sim compare.

: I think there is NO difference between DOS WorkView and the PROseries.  They
: even have the same bugs since ViewLogic never has enough time to fix them 
: (they release new products with the new bugs instead).  It applies both
: to schematic entry and simulation.

	How about the workview plus? Does it better than PROseries?
I've heard that it was placed on the higher rank(by viewlogic).

						Supaket K.

--

+--------------------------------------------
| Supaket Katchmart.
| Computer And Network System Research Lab.
| Dept. Computer Engineering. 
| Kasetsart University.
+--------------------------------------------
| E-Mail : b36skk@nontri.ku.ac.th
+--------------------------------------------


Article: 2261
Subject: Industry Trends
From: fsoehnge@ix.netcom.com (Frank Soehnge)
Date: 14 Nov 1995 02:28:10 GMT
Links: << >>  << T >>  << A >>
Greetings to all,

I have some questions regarding the current state of the industry and
where it is going. I work for BP Microsystems, a manufacturer of
universal device programmers, so I have a rather unique view of what is
popular and available among devices of all shapes and sizes. What I
would like to know is what everyone else thinks about topics such as
in-circuit programmability (both in prototyping and large scale
production), usefulness of SRAM devices, functional testing of modern
devices, low voltage devices and anything else you might think of as
either a God-send or a waste of time. I look forward to seeing your
responses. Please feel free to E-Mail me directly at erich@bpmicro.com.

Thanks,

Erich Wagner
BP Microsystems
1000 N. Post Oak Rd.
Houston TX. 77055


Article: 2262
Subject: Looking for large circuit
From: NAM MIN WOO <esfree>
Date: 14 Nov 1995 10:12:20 GMT
Links: << >>  << T >>  << A >>
I developed partition system.
It works at XNF, SXNF input.
I want to get large circuit for testing my system.
Data must be less than 196 Primary I/O.
I have ISCAS benchmark already,
I need more large circuit.
If you are interested in my system, and you have some large circuit
with XNF or SXNF form, please send me a mail.



Article: 2263
Subject: Re: AT&T vs. Xilinx
From: steve@sj.co.uk (Steve Wiseman)
Date: Tue, 14 Nov 1995 21:06:57 GMT
Links: << >>  << T >>  << A >>

>        How about the workview plus? Does it better than PROseries?
>I've heard that it was placed on the higher rank(by viewlogic).
>
>                                                Supaket K.
>
Hi, 
  after a year of fighting Dos Workview, then Proseries, both supplied as 
Xilinx locked systems, with VHDL, I'm looking at Workview Office, 
unlocked. It's not ready yet, but the bits I have are actually usable, 
quite unlike everything I've had before. It's possible to write VHDL and 
not have to fight the system, reboot many times, or resort to schematics 
to get the result I need. Paradise! I honestly couldn't recommend 
ProSeries if you're on any kind of a deadline, there are _far_ too many 
undocumented 'gotchas', and it's hard to sell VHDL that doesn't sanely 
support hierachy, and the only allowable data type is one that no-one 
else uses..... (And the manuals/sample code, ho bleeding ho....)
  It's been a bad year, toolwise, although I did manage to extract a nice 
twin P-90 machine in order to get the tools to at least blow up faster 
*8-)
  Still, the future's a vast amount better, Workview Office looks like a 
win, and, unless I've missed something, there's nothing better in the 
price range. Still, open to suggestions.... 


  All the best, especially to those struggling to get work done using 
ProSeries. (Mail me to swap cunning workarounds/bodges/horrors)

  Steve, speaking for Steve, not SJ. 
  





Article: 2264
Subject: Can Actel A12XX probe itself? (was: Can X30xx Reset itself?)
From: eric@granite.sentex.com (eric)
Date: 15 Nov 1995 03:18:54 GMT
Links: << >>  << T >>  << A >>
In article <peter-0911951718340001@149.199.19.143>, peter@xilinx.com (Peter Alfke) says:
>
>In article <47riv9$615@news-2.csn.net>, caleb@audiologic.com wrote:
>
>> Is it possible to configure a Xilinx 30xx IOB connected to RESET~
>> to successfully reset the chip? If so, how?
>
>Yes, it is possible to connect an output to the active Low RESET pin of
>any XC3000 device.
>There is no problem during configuration, since all outputs ( except LDC )
>are held High with a week pull-up resistor.

Is it possible to control the probing of the A12XXs by using 3 outputs
connected to the probe control pins (mode,sdi,dclk). This would save
the external register and associated address decode pld output required.

The local CPU typically has access to some r/w regs inside the design.
We tried it once and had to isolate the mode pin to get the design to
function. We had other things to work on and never got back around to it.

The programable probes have been invaluable. On most boards the fpga(s)
connect to everything, so it is often easier to connect the scope leads
to the fpga's probe points, and move the probes around on the board in
a virtual fashion (saves alot of fine pitch wear&tear). 

Eric Pearson - sans sig


Article: 2265
Subject: Re: Looking for large circuit
From: movahed@tumlis.lis.e-technik.tu-muenchen.de (M. Movahedin)
Date: Wed, 15 Nov 1995 09:34:48 GMT
Links: << >>  << T >>  << A >>
In article 1sq@ccsun2.sogang.ac.kr, NAM MIN WOO <esfree> writes:
> I developed partition system.
> It works at XNF, SXNF input.
> I want to get large circuit for testing my system.
> Data must be less than 196 Primary I/O.
> I have ISCAS benchmark already,
> I need more large circuit.
> If you are interested in my system, and you have some large circuit
> with XNF or SXNF form, please send me a mail.
> 


I have a design with 1778 CLBs. is it interesting ?

-mrm




Article: 2266
Subject: Xilinx XACT Windows Version
From: 0896892083-0003@t-online.de (Jan Kubuschok)
Date: Wed, 15 Nov 1995 15:55:21 +0000
Links: << >>  << T >>  << A >>
Hi!

I have trouble installing XAct for Windows. The problem is that the dongle 
can't be found by the software. Any idea??
The printerport works fine with an HP-Laserjet.
It's onboard a ASUS PT55XE with 32MB RAM and an 133mhz CPU.
Hope on help.

Jan.



Article: 2267
Subject: Re: Industry Trends
From: Rocky Awalt <rocky@trg.com>
Date: 15 Nov 1995 16:20:06 GMT
Links: << >>  << T >>  << A >>
Erich,

SRAM based devices are being used increasingly for "reconfigurable computers".

See;
 http://www.io.com/~guccione/HW_list.html
 http://www.reconfig.com/

In these applications the devices are reprogrammed in circuit. This is a growing 
application of SRAM based FPGAs.

-- 

Rocky Awalt                          The Rockland Group
rocky@trg.com                        7095 Pyramid Ct. <- shipping
http://www.trg.com/~fpga             P. O. Box 368  <- snail mail
916.622.7935 <- voice                Garden Valley, CA 95633-0368
916.622.7637 <- fax                  USA

 "Based in Northern California - TeleConsulting Worldwide"




Article: 2268
Subject: Re: AT&T vs. Xilinx
From: Baskaran Kasimani <jothi@singnet.com.sg>
Date: 15 Nov 1995 16:27:07 GMT
Links: << >>  << T >>  << A >>
This is the first time people find major bugs with the Viewlogic!

Tell me more and is very interesting.


jothi@singnet.com.sg




Article: 2269
Subject: Re: AT&T vs. Xilinx
From: Baskaran Kasimani <jothi@singnet.com.sg>
Date: 15 Nov 1995 16:27:34 GMT
Links: << >>  << T >>  << A >>
This is the first time people find major bugs with the Viewlogic!

Tell me more and is very interesting.


jothi@singnet.com.sg




Article: 2270
Subject: Re: Industry Trends
From: geneb@entropy.ultranet.com
Date: 16 Nov 1995 03:26:03 GMT
Links: << >>  << T >>  << A >>
In <488urq$l7j@ixnews5.ix.netcom.com>, fsoehnge@ix.netcom.com (Frank Soehnge) writes:
>Greetings to all,
>
>I have some questions regarding the current state of the industry and
>where it is going. I work for BP Microsystems, a manufacturer of
>universal device programmers,

<snip>

I realize you're seeking information about the direction of
devices, but some of my major concerns regard device 
programmers.
Every time a new device is announced, the real questions are
whose programmer will support it, how many iterations until
they get the bugs out (of both the device AND the programmer),
and how much the next "upgrade" to the so-called universal
programmer will be.
(This is not specific to one programmer manufacturer; it applies
to most of them).
Why does there seem to be a general antipathy between the device
and programmer manufacturers?  Why so much finger-pointing when
things go wrong?
I'd like to see new device announcements carry the logos of the 
programmers that are ready to handle the new parts.
Obviously, some of the device manufacturers hate to lose the
income from the sales of their proprietary programmers; are they
making more on the programmers than on the parts themselves?

In-circuit programming is a nice feature; just keep it simple, and the
voltages normal. 
SRAM-based parts can lead to chicken-egg problems in small systems
(how do you boot the part when it's responsible for accessing the
memory where the boot code resides?).

--Gene



Article: 2271
Subject: Thesis available: multi-FPGA systems
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Thu, 16 Nov 1995 00:25:06 -0600
Links: << >>  << T >>  << A >>
My thesis, entitled "Multi-FPGA Systems", is now available on the World-Wide
Web at http://www.eecs.nwu.edu/~hauck/Thesis.  It contains overviews of
digital logic implementation alternatives, multi-FPGA systems, and other
topics that may be of interest to many in this group.  I've included the
abstract and introductory chapter below.  If you have any questions or
comments, please let me know.

Scott Hauck
Assistant Professor - Northwestern University, Dept. of EECS
hauck@eecs.nwu.edu


Abstract

Multi-FPGA systems are a growing area of research.  They offer the
potential to deliver high performance solutions to general computing
tasks, especially for the prototyping of digital logic.  However, to
realize this potential requires a flexible, powerful hardware substrate
and a complete, high quality and high performance automatic mapping
system.

The primary goal of this thesis is to offer a disciplined look at the
issues and requirements of multi-FPGA systems.  This includes an in-depth
study of some of the hardware and software issues of multi-FPGA systems,
especially logic partitioning and mesh routing topologies, as well as
investigations into problems that have largely been ignored, including pin
assignment and architectural support for logic emulator interfaces.  We
also present Springbok, a novel rapid-prototyping system for board-level
designs.


Chapter 1:  General Introduction

In the mid 1980s a new technology for implementing digital logic was
introduced, the field-programmable gate array (FPGA).  These devices could
either be viewed as small, slow gate arrays (MPGAs) or large, expensive
programmable logic devices (PLDs).  FPGAs were capable of implementing
significantly more logic than PLDs, especially because they could
implement multi-level logic, while most PLDs were optimized for two-level
logic.  While they did not have the capacity of MPGAs, they also did not
have to be custom fabricated, greatly lowering the costs for low-volume
parts, and avoiding long fabrication delays.  While many of the FPGAs were
configured by static RAM cells in the array (SRAM), this was generally
viewed as a liability by potential customers who worried over the chipıs
volatility.  Antifuse-based FPGAs also were developed, and for many
applications were much more attractive, both because they tended to be
smaller and faster due to less programming overhead, and also because
there was no volatility to the configuration.

In the late 1980ıs and early 1990ıs there was a growing realization that
the volatility of SRAM-based FPGAs was not a liability, but was in fact
the key to many new types of applications.  Since the programming of such
an FPGA could be changed by a completely electrical process, much as a
standard processor can be configured to run many programs, SRAM-based
FPGAs have become the workhorse of many new reprogrammable applications. 
Some uses of reprogrammability are simple extensions of the standard logic
implementation tasks for which the FPGAs were originally designed.  An
FPGA plus several different configurations stored in ROM could be used for
multi-mode hardware, with the functionality on the chip changed in
reaction to the current demands.  Also, boards constructed purely from
FPGAs, microcontrollers, and other reprogrammable parts could be truly
generic hardware, allowing a single board to be reprogrammed to serve many
different applications.

Some of the most exciting new uses of FPGAs move beyond the implementation
of digital logic, and instead harness large numbers of FPGAs as a
general-purpose computation medium.  The circuit mapped onto the FPGAs
need not be standard hardware equations, but can even be operations from
algorithms and general computations.  While these FPGA-based
custom-computing machines may not challenge the performance of
microprocessors for many applications, for computations of the right form
an FPGA-based machine can offer extremely high performance, surpassing any
other programmable solution.  While a custom hardware implementation will
be able to beat the power of any generic programmable system, and thus
there must always be a faster solution than a multi-FPGA system, the fact
is that few applications will ever merit the expense of creating
application-specific solutions.  An FPGA-based computing machine, which
can be reprogrammed like a standard workstation, offers the highest
realizable performance for many different applications.  In a sense it is
a hardware Supercomputer, surpassing traditional machine architectures for
certain applications.  This potential has been realized by many different
research machines.  The Splash system [Gokhale90] has provided performance
on genetic string matching that is almost 200 times greater than all other
Supercomputer implementations.  The DECPeRLe-1 system [Vuillemin95] has
demonstrated world-record performance for many other applications,
including RSA cryptography.

One of the applications of multi-FPGA systems with the greatest potential
is logic emulation.  The designers of a custom chip need to verify that
the circuit they have designed actually behaves as desired.  Software
simulation and prototyping have been the traditional solution to this
problem.  However, as chip designs become more complex, software
simulation is only able to test an ever decreasing portion of the chipıs
functionality, and it is quite expensive in time and money to debug by
repeated prototype fabrications.  The solution is logic emulation, the
mapping of the circuit under test onto a multi-FPGA system.  Since the
logic is implemented in the FPGAs in the system, the emulation can run at
near real-time, yielding test cycles several orders of magnitude faster
than software simulation, yet with none of the time delays and
inflexibility of prototype fabrications.  These benefits have led many of
the advanced microprocessor manufacturers to include logic emulation in
their validation methodologies.

While multi-FPGA systems have great potential to provide high-performance
solutions to many applications, there are several problems that hold back
current systems from achieving their full promise.  Their hardware
structures tend to have much too few I/O connections for their logic
capacity to be adequately used.  This leads to very low logic utilization,
with only 10% to 20% of the available capacity usable.  While some of
these problems may be unavoidable, since we are using FPGAs targeted to
single-chip applications to build multi-chip systems, the routing
topologies of multi-FPGA systems need to be improved to compensate for
this.  Also, while there are logic emulation systems that meet the needs
of single-chip ASIC prototyping, the domain of system-level or board-level
prototyping has largely been ignored.  These emulation opportunities are
quite different from single chip systems, since multi-chip designs have a
heavy reliance on premade components, and have resource demands that vary
much more widely than that of a single ASIC.  Not only does board-level
prototyping demand a flexible and extensible emulation hardware system,
one that allows the inclusion of arbitrary premade components, but it also
brings into sharper focus the need to support external interfaces.  Even
in single-chip systems, one of the major benefits of an emulation is that
it may be capable of being put into its target environment, thus
encountering the true input-output demands of the final implementation. 
However, an emulation of a circuit will almost always run slower than the
final implementation, meaning that it will no longer meet the timing
requirements of the external signaling protocols.  Current emulation
systems have no answer to this problem, forcing the user to develop ad hoc
solutions.  For board-level prototyping, where a system will be required
to meet several signaling protocols at once, this problem becomes an even
greater concern.  Thus, a general-purpose solution to the logic emulator
interface problem is critical to the success of board-level prototyping,
and can improve emulations of individual ASICs as well.

The problems with current multi-FPGA systems are not solely with the
hardware.  Automatic mapping software is an important part of any
multi-FPGA system that hopes to achieve widespread utility, and is an
absolute requirement for any successful logic emulation system.  While
there are niches for multi-FPGA systems with hand-mapped solutions, very
few people are capable and willing to expend the effort to hand-map to a
multi-FPGA system, and without software these systems will only realize a
small portion of their promise.  Unfortunately, todayıs mapping software
is inadequate for most potential applications.  They deliver quite poor
mappings, and can take huge amounts of time to complete.  Creating a
mapping with current tools can take almost an entire day to finish. 
Obviously, this is a tremendous disadvantage, since any time savings that
could be achieved by running an algorithm on a multi-FPGA system is
swallowed up by the time to create the mapping in the first place.  Thus,
high-quality, high-performance mapping tools are a necessity for realizing
the full potential of multi-FPGA systems.

Part of the reason why these deficiencies exist in current multi-FPGA
systems is that there has been relatively little work done on optimizing
the hardware and software structures of these machines.  While there are a
huge number of multi-FPGA systems proposed and constructed, there are
almost no studies investigating what the best architectures really are. 
The software systems suffer as well, with many individual optimizations
proposed, but no real understanding of how to bring these optimizations
together to achieve the best possible results.  Thus, todayıs systems are
largely grab-bags of appealing features with little knowledge of what the
systems should really look like.

In 1992 we were in the same position as many other potential multi-FPGA
system builders.  We saw the need for a new system, which in our case was
an emulation system optimized for the demands of board-level prototyping. 
While we knew in general what the system should look like, there was
little guidance on exactly what the hardware and software architecture
should be.  At this point, instead of blindly going forward with our best
guesses on how the system should be, we set out to look at the underlying
issues and determine what really were the right architectures.  By
performing a disciplined investigation of multi-FPGA hardware and software
systems, we not only would learn how to build our prototyping system
correctly, but would also give a better understanding of some of the
issues to the multi-FPGA community at large.  It is these investigations
that form the heart of this thesis.  While we have not yet built our
prototyping system (the high-level design of which is contained in Chapter
6), our work has yielded insight into many of the problems facing todayıs
multi-FPGA systems.

Our investigations have focused on several different areas.  In the
hardware arena, we examined the routing topologies of multi-FPGA systems. 
Although the FPGAs in a multi-FPGA system are reprogrammable, the
connections between the FPGAs are fixed by the circuit board implementing
the system.  With the main bottleneck in current multi-FPGA systems being
the limited bandwidth for inter-FPGA routing, the routing topology of a
multi-FPGA system has a significant impact on the capacity, as well as
performance, of a multi-FPGA system.  In our investigations we examined
how best to construct a multi-FPGA system, yielding topologies with
significantly lower I/O requirements, faster performance, and higher
bandwidth.

Since our goal was to construct a prototyping system for board-level
designs, we also had to consider the issue of how to support the external
interfaces of a logic emulation system.  By examining how to solve this
problem in general, we have shown that a generic interface transducer, a
simple board with FPGAs and memories for filtering the incoming and
outgoing datastreams, is capable of supporting many different types of
protocols.  It has a flexible architecture that enables it to be
prefabricated, yet it still allows customization to a specific
applicationıs requirements.  Also, the required customization is easy to
develop, and a small amount of programming in a high-level hardware
description language is usually sufficient.

We have also spent time investigating the software required to map to a
multi-FPGA system.  Perhaps the most critical of these algorithms is
partitioning, the process of splitting an input mapping into pieces small
enough to fit into the individual FPGAs in a multi-FPGA system.  While
much work has been done on this problem previously, there was little
insight into the best possible approach.  Many researchers have proposed
software solutions, but there was little comparative assessment of
different approaches.  Thus, one major portion of our work was to sift
through the different approaches, and develop an algorithm that brings
together the best possible set of optimizations to achieve the best
overall results.  This produced a survey of many of the different
approaches, with each optimization implemented in a common framework, and
compared quantitatively on a set of benchmark circuits.  We now have an
algorithm that produces results significantly better and faster than any
other published approach.

We also recognized that flexible routing topologies are becoming more
common in multi-FPGA systems, with architectures capable of significant
customization in their interconnection patterns being proposed.  To deal
with these systems, it became apparent that the mapping tools not only
needed to be fast and high-quality, but they also must be able to adapt to
an arbitrary topology.  This is not only important for flexible multi-FPGA
hardware, but it also results in software that can easily be adapted to
different machines.  In pursuit of this goal, we have developed
partitioning software capable of mapping to an arbitrary multi-FPGA system
topology, as well as routing software that can do the same.  This routing
software has the added advantage that it improves the quality of the
mapping over current approaches, yielding both better-quality mappings and
faster run-times.  This latter benefit is due to the fact that poor
routing complicates the following mapping steps, and thus by improving the
routing quality we decrease the total mapping time.

The result of all of this work is new insights into how best to build and
use multi-FPGA systems, as well as solutions to some of the outstanding
problems.  These results are not just important for building prototyping
systems like the one we envisioned, but to multi-FPGA systems in general. 
The routing topologies are generally useful, offering improved topologies
for both emulation and custom-computing.  The mapping tools provide fast,
high-quality mapping solutions for arbitrary system topologies.  Finally,
the interface transducers deliver a generic solution for interfacing both
current single-chip emulators, as well as future board-level prototyping
systems.

This thesis details the results of these investigations.  It begins with a
discussion of the underlying technologies that make multi-FPGA systems
practical, including a survey of FPGAs and other logic implementation
technologies in Chapter 2, as well as the application domains of
multi-FPGA systems in Chapter 3.  Chapter 4 delves deeper into one of the
most promising application areas for multi-FPGA systems, logic emulation. 
Chapter 5 then gives an overview of current multi-FPGA system hardware. 
With the background provided by these chapters, we then present some new
investigations and approaches to multi-FPGA system hardware.  In Chapter 6
we present a new multi-FPGA system optimized for the prototyping of
board-level designs.  This system combines the inclusion of arbitrary
devices with a flexible and extensible architecture to provide an
extremely adaptable prototyping solution.  Then, Chapter 7 examines
routing topologies for multi-FPGA systems.  This yields constructs with
lower I/O demands, smaller delays, and higher bandwidth than standard
topologies.  Finally, Chapter 8 investigates how to support external
interfaces for logic emulators, one of the significant problems with
current systems.

The discussion of multi-FPGA system software begins with a general
introduction in Chapter 9.  Chapter 10 considers logic partitioning for
multi-FPGA systems, presenting a comprehensive investigation into
bipartitioning techniques.  This results in a combined partitioning
algorithm that achieves results better than the current state of the art,
in significantly less time.  Chapter 11 presents an iterative partitioning
algorithm that automatically adapts to an arbitrary topology.  This allows
bipartitioning to be applied to any multi-FPGA system, as well as
multi-sectioning and multi-way partitioning algorithms where appropriate. 
Finally, Chapter 12 investigates pin assignment algorithms for multi-FPGA
systems.  This speeds up the placement and routing time for multi-FPGA
systems and produces higher quality results.  We conclude this thesis with
some overall results and potential future work in Chapter 13.
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
|               Scott A. Hauck, Assistant Professor                         |
|  Dept. of EECS                       Voice: (708) 467-1849                |
|  Northwestern University             FAX: (708) 467-4144                  |
|  2145 Sheridan Road                  Email: hauck@eecs.nwu.edu            |
|  Evanston, IL  60208                 WWW: http://www.eecs.nwu.edu/~hauck  |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+


Article: 2272
Subject: [Q] FPGA Software for Linux
From: bon@elektron.ikp.physik.th-darmstadt.de (Uwe Bonnes)
Date: 16 Nov 1995 08:54:56 GMT
Links: << >>  << T >>  << A >>
Hallo,

is there any software to design FPGAs available for the Linux Operating
system or planned to be available in the next future?

Thanks

-- 
Uwe Bonnes                bon@elektron.ikp.physik.th-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 2273
Subject: Re: Industry Trends
From: rob@pe1chl.ampr.org (Rob Janssen)
Date: Thu, 16 Nov 1995 12:23:03 GMT
Links: << >>  << T >>  << A >>
In <48d3vm$945@harry.lloyd.com> Rocky Awalt <rocky@trg.com> writes:

>Erich,

>SRAM based devices are being used increasingly for "reconfigurable computers".

>See;
> http://www.io.com/~guccione/HW_list.html
> http://www.reconfig.com/

>In these applications the devices are reprogrammed in circuit. This is a growing 
>application of SRAM based FPGAs.

SRAM??  Shouldn't that read EEPROM?

Rob
-- 
+------------------------------------+--------------------------------------+
| Rob Janssen         rob@knoware.nl | AMPRnet:   rob@pe1chl.ampr.org       |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+


Article: 2274
Subject: WHO WAS THE XACT'S PROGRAMMER?
From: <cha>
Date: 16 Nov 1995 14:59:41 GMT
Links: << >>  << T >>  << A >>
You've done a good job!!!!!!!!!!!!


        Xblox changed itself the name of my design.
        Fileinput=xc_ram2
        Fileoutput=xc_ram2.xg

        but the real output was XCRAM2.XG. (oh, oh,....)
         
        Can you speak spanish? (joputa)

        Hi de puta , D. Quijote said to Sancho, so don't offend yourself by
        what I tell you when angry....





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
2017JanFebMarApr2017

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