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 3175

Article: 3175
Subject: Re: Power consumption of Xilinx device
From: Scott Kroeger <scott.kroeger@mei.com>
Date: Thu, 18 Apr 1996 08:43:27 -0500
Links: << >>  << T >>  << A >>
Rolf V. =?iso-8859-1?Q?=D8stergaard ?= wrote:
> 
> For a given design, what can be done to reduce the power consumption of
> a Xilinx 3020 device? I think in terms of special routing, unused nets
> etc.
> 
> Anyone got any ideas on how much I could expect to reduce the power
> consumption using "after-design" techniques only? 10%, or?

Without knowing the details of the design, its impossible to guess what kind of 
power reduction you might achieve.  However there are some basic guidelines.

First the easy and obvious things:
1) Use 3020L if your design doesn't need the speed (3020A if it does).
2) Set the input threshold to CMOS.
3) Use makebits TIE option.
4) Avoid input and longline pullups unless you know those lines will be 
primarily high.
5) Run at 3V.

For more power savings:

Where possible, implement ripple dividers rather than synchronous.

If your design has few FF's running from the main clock, you could use ACLK 
(instead of GCLK) and constrain your clocked logic to one or a few vertical 
columns.  Whereas the GCLK net covers the entire device, the ACLK net drives a 
horizontal line which selectively drives vertical clock lines.  Columns that 
contain no FFs using ACLK will not be driven.  This might save a little power in 
the ACLK net.  You can also use direct clocks to small blocks of logic (if you 
place manually to guarantee clock skew in the correct direction).  You can place 
longline flags on little clock nets (by little I mean small enough to fit on a 
longline).

Non global clocks can be gated off when not used.  Be careful!

Makebits TIE will tie unused inputs to anything it can, including fast clocking 
outputs.  After doing the TIE look at the report and see if any unused inputs 
were hung on fast clocking signals.  If so, you might try a re-route or manual 
re-connection of the unused inputs to slower moving signals. (Makebits usually 
seems to do an OK job, so you might not be able to improve on it).

This might improve things 5% +- 10% :)

Have fun,
Scott


Article: 3176
Subject: Re: Crosspoint Solutions
From: Markus.Wannemacher@FernUni-Hagen.De (Markus Wannemacher)
Date: 18 Apr 1996 16:30:48 GMT
Links: << >>  << T >>  << A >>
Charles Gardiner ("100421,3461"@compuserve.com) wrote:
: Does anyone know if Crosspoint Solutions Inc., a FPGA manufacturer based 
: in milpitas CA, have a page on the WWW?

: Thanks in advance,

: Charles

All I found about Crosspoint Solutions on the WWW are some infos
about the CP20K series at the synopsys site:

  http://www.synopsys.com/partnerships/svp/cross_fsvp.html

Markus Wannemacher

---
Markus Wannemacher, FernUniverit"at Hagen, Lehrgebiet Informationstechnik
D-58084 Hagen, Germany     E-Mail: Markus.Wannemacher@FernUni-Hagen.De
phone +49 2331 987 4547    WWW:    http://www.fernuni-hagen.de/IT/wm.html
fax   +49 2331 987 375     talk:   wm@tokyo.fernuni-hagen.de   



Article: 3177
Subject: Do ECL, PECL gate arrays or FPGAs exist?
From: filippo@rice.edu (Michael Alan Filippo)
Date: 19 Apr 1996 15:20:23 GMT
Links: << >>  << T >>  << A >>



Article: 3178
Subject: ECL, PECL gate arrays or FPGA's
From: Michael Filippo <filippo@rice.edu>
Date: Fri, 19 Apr 1996 10:26:40 -0500
Links: << >>  << T >>  << A >>
Let me try it again...

Does anyone know where (or if) I can get ECL or PECL (preferrable) gate arrays
or FPGAs?  I'm trying to design a high-speed (100 MHz) crossbar switch and I need
some way to build multiple multi-bit 16-1 MUXs.  I've looked at Lattice's CPLDs
(1K, 2K, and 3K families), but I have serious doubts about their performance.  I'm
laess concerned with the propagation delay than I am about the output edge rates.  I
assume I can skew the clock for the receiving latch to compensate for the prop.
delay (assuming I can fix it in a range), but I can't very well have a 10 ns period
if I have 5ns (or more) edge rates.  Any suggestions?

-- 
Mike Filippo    
filippo@rice.edu  
http://www-ce.rice.edu/ce/members/filippo/htdocs/filippo.html


Article: 3179
Subject: Re: ECL, PECL gate arrays or FPGA's
From: peter@xilinx.com (Peter Alfke)
Date: 19 Apr 1996 17:03:43 GMT
Links: << >>  << T >>  << A >>
In article <3177B0B0.41C67EA6@rice.edu>, Michael Filippo
<filippo@rice.edu> wrote: 
> Does anyone know where (or if) I can get ECL or PECL (preferrable) gate arrays
> or FPGAs?  I'm trying to design a high-speed (100 MHz) crossbar switch
and I need
> some way to build multiple multi-bit 16-1 MUXs.

I suggest the Xilinx XC3164, XC3190 or XC3195. The newest -1, and the
upcoming -09 speed grade are very fast, and the wide mux can be
implemented on Longlines.Of course, everything gets much easier if you can
tolerate one level of pipelining.

The problem with ECL ( PECL is just ECL run on +5V ) is the small logic
swing and its absolute level,slightly negative with respect to the
positive supply rail.

Peter Alfke, Xilinx Applications


Article: 3180
Subject: On FPGAs as PC coprocessors
From: jsgray@ix.netcom.com(Jan Gray)
Date: 19 Apr 1996 18:18:23 GMT
Links: << >>  << T >>  << A >>
One of the questions I heard at FCCM this year was "when, if ever, will
an FPGA coprocessor ship on every PC motherboard?"

Looking at current approaches to FPGA "coprocessors", the answer must
be "not any time soon".

Consider that today's power user's CPU (such as a 200 MHz Pentium Pro
or a 400 MHz Alpha 21164A) *running out of L1 cache* issues peak three
or four instructions per 2.5-5 ns clock.  Also consider that the
current "low latency high bandwidth" approach to FPGA coprocessor
integration is to hang the FPGA on the PCI bus.

In this scenario, the kinds of quasi-general purpose computing problems
that an FPGA coprocessor can usefully assist with are quite limited. 
Issuing a write and then a read back operation to the FPGA could easily
take 10 PCI bus cycles (300 ns), even assuming no PCI bus contention. 
In that time a Pentium Pro could issue as many as 180 instructions; the
Alpha, 480 64-bit instructions. Future versions of such processors will
soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism,
and eventually superscalar versions of same, so next year's 200-400 MHz
implementations could issue between 500 (*) and 4000 (**) hand coded
packed byte operations before that single FPGA write/read completes!

(*) forthcoming 200 MHz PPro with MMX: 60 clocks x 1 8-byte MMX
insn/clock

(**) hypothetical 400 MHz Alpha with each integer unit enhanced for
bytewise SIMD: 120 clocks x 4 8-byte insns/clock

((At peak speeds like 4e8 clocks/s * 4 issue/clock * 8 byte ops/issue,
e.g. 1.2e10 byte ops/s, you have to agree that superscalar micros with
bytewise SIMD are going to displace many computational FPGA
applications on PC and workstation platforms.))

So as long as FPGAs are attached on relatively glacially slow I/O buses
-- including 32-bit 33 MHz PCI -- it seems unlikely they will be of
much use in general purpose PC processor acceleration.  Sure, for
apFrom: jsgray@ix.netcom.com(Jan Gray)
Newsgroups: comp.arch.fpga
Subject: On FPGAs as PC coprocessors

One of the questions I heard at FCCM this year was "when, if ever, will
an FPGA coprocessor ship on every PC motherboard?"

Looking at current approaches to FPGA "coprocessors", the answer must
be "not any time soon".

Consider that today's power user's CPU (such as a 200 MHz Pentium Pro
or a 400 MHz Alpha 21164A) *running out of L1 cache* issues peak three
or four instructions per 2.5-5 ns clock.  Also consider that the
current "low latency high bandwidth" approach to FPGA coprocessor
integration is to hang the FPGA on the PCI bus.

In this scenario, the kinds of quasi-general purpose computing problems
that an FPGA coprocessor can usefully assist with are quite limited. 
Issuing a write and then a read back operation to the FPGA could easily
take 10 PCI bus cycles (300 ns), even assuming no PCI bus contention. 
In that time a Pentium Pro could issue as many as 180 instructions; the
Alpha, 480 64-bit instructions. Future versions of such processors will
soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism,
and eventually superscalar versions of same, so next year's 200-400 MHz
implementations could issue between 500 (*) and 4000 (**) hand coded
packed byte operations before that single FPGA write/read completes!

(*) forthcoming 200 MHz PPro with MMX: 60 clocks x 1 8-byte MMX
insn/clock

(**) hypothetical 400 MHz Alpha with each integer unit enhanced for
bytewise SIMD: 120 clocks x 4 8-byte insns/clock

((At peak speeds like 4e8 clocks/s * 4 issue/clock * 8 byte ops/issue,
e.g. 1.2e10 byte ops/s, you have to agree that superscalar micros with
bytewise SIMD are going to displace many computational FPGA
applications on PC and workstation platforms.))

So as long as FPGAs are attached on relatively glacially slow I/O buses
-- including 32-bit 33 MHz PCI -- it seems unlikely they will be of
much use in general purpose PC processor acceleration.  Sure, for
applications such as cryptography, image and signal processing, they
might be a win, given a semi-autonomous problem which either fits in
the FPGA and local storage, or which can employ DMA to stream data into
or through the FPGA without much CPU intervention or management.

A decimal order of magnitude less access latency could be achieved if
FPGA vendors provide a way to directly connect their parts to the
Pentium Pro external bus, as a peer of the memory/bus controller.  A
custom, dedicated Pentium Pro interface would probably be required,
since FPGA configurable logic would be slow and electrically
incompatible.

Of course, the PCI ASIC crowd has the same latency problems, but they
don’t have aspirations of changing general purpose computing.

(Acknowledgement: this posting is a spin-off of a discussion with Mark
Shand.)

Jan Gray
Redmond, WA



Article: 3181
Subject: Re: On FPGAs as PC coprocessors
From: Scott Kroeger <scott.kroeger@mei.com>
Date: Sat, 20 Apr 1996 10:14:23 -0500
Links: << >>  << T >>  << A >>
Jan Gray wrote:
> 
> One of the questions I heard at FCCM this year was "when, if ever, will
> an FPGA coprocessor ship on every PC motherboard?"
> 
> Looking at current approaches to FPGA "coprocessors", the answer must
> be "not any time soon".

(snip)

> Alpha, 480 64-bit instructions. Future versions of such processors will
> soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism,
> and eventually superscalar versions of same, so next year's 200-400 MHz
> implementations could issue between 500 (*) and 4000 (**) hand coded
> packed byte operations before that single FPGA write/read completes!
> 

(snip)

> 
> So as long as FPGAs are attached on relatively glacially slow I/O buses
> -- including 32-bit 33 MHz PCI -- it seems unlikely they will be of
> much use in general purpose PC processor acceleration.  Sure, for
> applications such as cryptography, image and signal processing, they
> might be a win, given a semi-autonomous problem which either fits in
> the FPGA and local storage, or which can employ DMA to stream data into
> or through the FPGA without much CPU intervention or management.

(snip)

The FPGA belongs on the CPU die.  Once there it gets "free" use of much of the CPU's 
facilities (registers, cache, memory interface etc).  This should allow the FPGA to 
achieve performance improvements over the CPU for operations too wierd to be 
contemplated in the normal instruction set.  For example, think how easy it would be to 
rewire an ALU to perform CRC.

I expect (hope) to see FPGAs on low end embedded chips as well.  What else are we going 
to use all that silicon for!

Cheers,
Scott


Article: 3182
Subject: Re: VHDL conversion function from int to time ...?
From: vijayn@cdac.ernet.in (Vijay A Nebhrajani)
Date: Sat, 20 Apr 1996 17:03:58 GMT
Links: << >>  << T >>  << A >>

In article <Dpwv0C.zq@bri.hp.com>, andrew@warp6.bri.hp.com (Andrew Hana) writes:
:->    signal_of_type_time    <= signal_of_type_integer * 1 ns;
:->  
:->    signal_of_type_integer <= signal_of_type_time    / 1 ns;
:->
:->
:->Note that the space between `1' and `ns' is important!!
:->
:->Andrew


Thanks, Andrew!

-- vijay




Article: 3183
Subject: Re: Low-power FPGA or EPLD
From: Andrew Metcalfe <metcalfe@ozemail.com.au>
Date: Sun, 21 Apr 1996 11:39:21 +1100
Links: << >>  << T >>  << A >>
Joe Hass wrote:
> 
> I'm looking for an FPGA or EPLD to replace about a dozen CMOS
> MSI and SSI parts.  I expect to need about 40 I/Os. A very

John, the Xilinx XC3030L part may be what you need. The static consumption is <30uA and the part will run down 
to 3V. Very nice, tidy part.

-Andrew Metcalfe


Article: 3184
Subject: Re: What bus is a Xilinx XC1736DP SPROM?
From: Andrew Metcalfe <metcalfe@ozemail.com.au>
Date: Sun, 21 Apr 1996 11:42:10 +1100
Links: << >>  << T >>  << A >>
David A Willmore wrote:
> 
> I'm tyring to drop in a EEPROM for one of these chips and I
> can't find out what bus this part uses.  First, am I SOL to
> start with or is this possible?  I can speak IIC, uWire, and
> from there, SPI, et al are easy.  (it's a serial protocol,
> how hard can it be?)
> 
> I don't have any Xilinx documentation, so can anyone give me
> a hand?
> 
> Cheers,
> David

David, the parts have a proprietary, high speed interface. Xilinx sell serial proms for these parts and also 
have specifications on their web site. Contact www.xilinx.com.

The parts can be cascaded to make lkarger ones and are somewhat denser than standard eeprom parts. 

-Andrew Metcalfe


Article: 3185
Subject: looking for xnf-to-blif conversion tool
From: Mohammed Khalid <khalid@eecg.toronto.edu>
Date: Sun, 21 Apr 1996 21:29:42 GMT
Links: << >>  << T >>  << A >>

I need to convert circuit netlists from xnf format to blif format. If anybody
has such a tool (or knows where it's available) please let me know.

Any help in this matter will be greatly appreciated.

Khalid

(email: khalid@eecg.toronto.edu)



Article: 3186
Subject: looking for 'synthesizable' VHDL/Verilog ASIC models
From: Mohammed Khalid <khalid@eecg.toronto.edu>
Date: Sun, 21 Apr 1996 21:57:32 GMT
Links: << >>  << T >>  << A >>

I need large benchmark circuits for my research work on Multi-FPGA     
Field-Programmable Systems (FPSs). I am looking for circuits that consist of
> 3K 4-LUTs plus flip flops. Since large circuits are hard to find, I could
use 'synthesizable' VHDL/Verilog ASIC models. I have access to Exemplar and
Synopsys synthesis tools. If anybody has such models (or knows where they are
available) please let me know.

Thanks in advance for any information on this matter.

Khalid

(email: khalid@eecg.toronto.edu)



Article: 3187
Subject: Re: On FPGAs as PC coprocessors
From: graeme@wallaby.digideas.com.au (Graeme Gill)
Date: 22 Apr 1996 09:54:00 +1000
Links: << >>  << T >>  << A >>
Scott Kroeger (scott.kroeger@mei.com) wrote:

: The FPGA belongs on the CPU die.  Once there it gets "free" use of much of the CPU's 
: facilities (registers, cache, memory interface etc).  This should allow the FPGA to 
: achieve performance improvements over the CPU for operations too wierd to be 
: contemplated in the normal instruction set.  For example, think how easy it would be to 
: rewire an ALU to perform CRC.

Hmm. Ever thought about how such a chip is going to switch context ?

(Similar problems confront programable instruction sets.)

: I expect (hope) to see FPGAs on low end embedded chips as well.  What else are we going 
: to use all that silicon for!


	Graeme Gill.


Article: 3188
Subject: Inferring or design ware (modgen)?
From: flxchen@diig.dlink.com.tw (Felix K.C. CHEN)
Date: Mon, 22 Apr 1996 18:14:17 +800
Links: << >>  << T >>  << A >>
Dear Friends,

I am designing a FPGA whose main function is a multi-channel DMA
engine.  As you know that DMA engines consists of many counters.
The counters I need are not simple "incrementers".  They are loadable,
count enable and asynchronous clear.

we all know that VHDL synthesizer from both Synopsys and Exemplar
can infer counter from VHDL operators "+" and "-".  But they also
provide users with the alternative of technology independant
component instantiation for counters, called design ware with
Synopsys and Modgen with Exemplar.  By chance my company have
them both.

Because the synthesized result of my design is so large that I
can not help suspect that the inferring style I used (please see
the sample code below) is not efficient.

I'd like to try the component instanitiation alternative.  But
I will have to modify my source code.  At least I have to rebuild
the design hierarchy when I extract the counter out of the state
machine.  So before I do this engineering, I ask you
for any opinion about these two approaches.

With component instantiation appraoch, will there be any improvement on
the control signal generating logic, like LOAD CONTROL and COUNT ENABLE?

Regards,

Felix K.C. CHEN

-- the sample code

process: counter(RESETZ, CLK, state, count, ...)
begin
if (RESETZ='0') then
  count <= 0;
elsif (CLK'event and CLK='1') then
  case state is
  when S1 =>
    if (condition) then
      count <= load_value_1; -- load the counter
    end if;
  when S2 =>
    if (condition) then
      count <= 0; -- clear the counter, a load too
    end if;
  when S3 =>
    if (condition) then
      count <= count + "1";  -- count up
    end if;
  when S4 =>
    if (condition) then
      count <= count + "1"; -- count up
    end if;
  when S5 =>
    if (condition) then
      count <= count + "1";  -- count up
    end if;
  when others =>
    null;
  end case;
end if;
end process;



-- 
---------------------------------
Felix, Kuan-chih CHEN (³¯ «a §Ó)
Associate Project Manager
System Product Division
D-Link Co., Hsin-chu, Taiwan
Email: flxchen@diig.dlink.com.tw

Machines and tools are only as
good as the people who use it.
---------------------------------

-- 
---------------------------------
Felix, Kuan-chih CHEN (³¯ «a §Ó)
Associate Project Manager
System Product Division
D-Link Co., Hsin-chu, Taiwan
Email: flxchen@diig.dlink.com.tw

Machines and tools are only as
good as the people who use it.
---------------------------------



Article: 3189
Subject: Comp.arch.fpga FAQ- Frequently Asked Questions List
From: Richard_Vireday@ccm.jf.intel.com (Richard Vireday)
Date: Mon, 22 Apr 1996 17:31:42 GMT
Links: << >>  << T >>  << A >>
Since FCCM'96 just ended, I thought it would be time to repost the
updated FAQ.  This FAQ has now doubled in size from earlier versions.


===================================================================
Comp.arch.fpga FAQ - Frequently Asked Questions List

1. Is there an FAQ for comp.arch.fpga?

	Answer:  No.


2. But, but what about my {PLD|FPGA|ASIC|Tools|...}+ questions??????

	Answer:  Forget it.

===================================================================
For more information, consult the following lists.
        http://www.super.org:8000/FPGA/
        http://www.<fpga vendor of choice>.com/


Article: 3190
Subject: Serial EEPROMs
From: * Atmel FPGA Apps * <martin@atmel.com>
Date: Mon, 22 Apr 1996 17:56:55 GMT
Links: << >>  << T >>  << A >>

 
David A Willmore wrote:
> 
> I'm tyring to drop in a EEPROM for one of these chips and I
> can't find out what bus this part uses.  First, am I SOL to
> start with or is this possible?  I can speak IIC, uWire, and
> from there, SPI, et al are easy.  (it's a serial protocol,
> how hard can it be?)
> 

David,
	Atmel makes a pin compatable EEPROM device that emulates the 
industry standard 17Cxxx FPGA configuration OTP proms.  The AT17Cxxx 
devices are (re)programmable and can be loaded in system via an industry 
standard 2-wire serial protocol.  The parts are available in 17C65 and 
17C128 densities now and 17c256 early Q3 (July) - thay are available in 8 
pin dip, 20 pin plcc and 20 pin soic.  For more information e-mail me - 
check out http:/www.atmel.com or use our Fax-on-Demand 1-800-29-ATMEL 
(request documents 602, 603, 604 and 663).

Regards,

Martin.

-------------------------------------------------------------------------
|       Martin Mason            | Snr FPGA/17Cxxx Applications Engineer |
|       Atmel Corp.             | (email - me)         martin@atmel.com |
|       2325, Orchard Parkway   | (email - support)      fpga@atmel.com |
|       San Jose                | (Fax)         + (408) 436 4300        |
|       CA 95131    USA         | (Tele)        + (408) 436 4178        |
-------------------------------------------------------------------------
|Need Atmel Lit. stuff ?  WWW.ATMEL.COM or FAX-on-DEMAND 1-800-29-ATMEL | 
-------------------------------------------------------------------------



Article: 3191
Subject: Re: What bus is a Xilinx XC1736DP SPROM?
From: David Wilkie <david.wilkie@microchip.com>
Date: Mon, 22 Apr 1996 12:09:16 -0700
Links: << >>  << T >>  << A >>
Andrew Metcalfe wrote:
> 
> David A Willmore wrote:
> >
> > I'm tyring to drop in a EEPROM for one of these chips and I
> > can't find out what bus this part uses.  First, am I SOL to
> > start with or is this possible? 
> >
> > I don't have any Xilinx documentation, so can anyone give me
> > a hand?

> David, the parts have a proprietary, high speed interface. Xilinx sell serial proms for these parts and also
> have specifications on their web site.
> 
> The parts can be cascaded to make lkarger ones and are somewhat denser than standard eeprom parts.

Microchip also makes these devices. They are 37LV36, 37LV64, and 37LV128, 
with 36, 64, and 128K memory respectively.

Contact Microchip at 602 786 7200, or web us at 
http://www.ultranet.com/biz/mchip for datasheets, contacts, etc.

David
-- 

The views expressed in this message are mine and are not necessarily 
representative of Microchip Technology Inc. While every effort has
been made to ensure accuracy, please don't be upset if I got 
something wrong. Just tell me.


Article: 3192
Subject: Re: Looking for FPGA Boards taking Xilinx 4000 series FPGA
From: "Steve Knapp (Xilinx, Inc.)" <stevek>
Date: 22 Apr 1996 23:36:26 GMT
Links: << >>  << T >>  << A >>
"S.C.Lim" <elscl@lboro.ac.uk> wrote:
>Hi,
>
>Our research group is looking into purchasing circuits boards that will
>take one to a few Xilinx 4020 FPGA chips. These Boards are to be used
>for circuit verifications by downloading design using Xilinx's Xact
>cable. If the board contains multiple chips, they should all be able to
>be programmed using a single xact cable link.
>
>If you have such kind of boards avaliable for sale or know anybody who
>supplies them, please mail me at  S.C.Lim@lboro.uc.uk.

--  I believe that Aptix offers such a board that accomodates multiple
FPGA devices.  You can contact them via E-mail at sales@aptix.com
and they have a Web site at http://www.aptix.com, though I didn't find
much there.
=====================================================================
   _
  / /\/  Steven K. Knapp               E-mail:  stevek@xilinx.com 
  \ \    Corporate Applications Mgr.      Tel:  1-408-879-5172 
  / /    Xilinx, Inc.                     Fax:  1-408-879-4442
  \_\/\  2100 Logic Drive                 Web:  http://www.xilinx.com
         San Jose, CA 95124

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



Article: 3193
Subject: The problem with ECL (was Re: ECL, PECL gate arrays or FPGA's)
From: husby@fnal.gov (Don Husby)
Date: 23 Apr 1996 13:12:07 GMT
Links: << >>  << T >>  << A >>
peter@xilinx.com wrote:
> The problem with ECL ( PECL is just ECL run on +5V ) is the small logic
> swing and its absolute level,slightly negative with respect to the
> positive supply rail.

Errr... that would be "The advantage of ECL is the small, non saturated, logic 
swing and it's nearness to the very quiet ground".  ECL is inherently way less
noisy than TTL.

The PROBLEM with ECL is it's huge power consumtion, low integration levels,
and large price tag.

At any rate, Xilinx 3100-9 seems to compete very well in the traditionally
ECL speed domain.  Although we haven't used it yet, we are considering
using it (instead of ECL) to drive a 200MHz parallel optical link.



Article: 3194
Subject: Re: ECL, PECL gate arrays or FPGA's
From: husby@fnal.gov (Don Husby)
Date: 23 Apr 1996 14:09:40 GMT
Links: << >>  << T >>  << A >>
  I-cube makes a crossbar switch that may be just what you're looking for.
It claims to have a 150MHz clocked data throughput.  It's fairly
fast at re-configuring, although it will take several cycles to configure
if you're using a single chip to switch a wide data path.

                  http://www.icube.com/NavMap.html

  Also, Tri-quint makes some very fast (>1GHz) switches in a GaAs technology.

  Also, if you're interested, I have used an ORCA 2C12 to implement a fully
buffered 4x4 crossbar with the following specifications:

4 input ports switched on a per-cycle basis to 4 output ports
via an array of sixteen 24-bit wide FIFOs.  Can sustain a throughput
of 40ns per word per port.  Can be ganged for arbitrary word width or
cascaded for arbitrary switch size.  Each port is controlled by a 2-bit
destination address and a valid bit.  24-bit data is transferred as 12 bits
each on the rising and falling edge of a 40ns clock.

This design could be doubled in speed using the new 4000E with clocked, 
dual-port RAM   Although you'd probably have to trim the size to about 8 bits 
wide.  ORCA has announced a clocked-RAM version of it's chips, due out at the
end of 96?




Article: 3195
Subject: Application Question
From: li@news.cs.columbia.edu (Zhe Li)
Date: 23 Apr 1996 12:59:10 -0400
Links: << >>  << T >>  << A >>


Hi there,
 
Could someone shed some lights on how to achieve the following task
or share some references i could followup?
 
I have an image application written in C running on a Sun Sparc 10.
After hearing something about FPGA, I was wondering whether it is
possible to implement the most expensive function in FPGA to speed
up my application.  Since I am not a hardware person, it is unclear
to me how to proceed.  Once the FPGA is programmed, how will my 
application (or the operating system) know to branch to the FPGA
to execute that expensive function instead of executing the function
in the old way?

Regards!

- Jay

Please email response to li@cs.columbia.edu and I will post a summary
if there are enough interests.



Article: 3196
Subject: Re: 8051-type macrocell available
From: "koch@mikro.uni-stuttgart.de" <koch@mikro.uni-stuttgart.de>
Date: 23 Apr 1996 18:19:32 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

---------------------------------582738540344227893964226250
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

-- 
*****************************************************************
name:    Michael Koch			   __    ____
depart:  Zentrale Tools			  |  \  |_______ 
company: IMS 				  -   \_________|
adress:  Allmandring 30a	       ____
         70569 Stuttgart 		  |     /\    /\
         Germany			  |    /  \  /  \
phone:   xx49-711-685 5897		 _|___/   _\/   _\
fax:     xx49-711-685 5930
psi-mail: PSI%45711010172::KOCH
e-mail:   koch@mikro.uni-stuttgart.de
*****************************************************************

---------------------------------582738540344227893964226250
Content-Transfer-Encoding: 7bit
Content-Type: text/plain

Article: 3197
Subject: Re: The problem with ECL (was Re: ECL, PECL gate arrays or FPGA's)
From: peter@xilinx.com (Peter Alfke)
Date: 23 Apr 1996 22:01:50 GMT
Links: << >>  << T >>  << A >>
In article <4likv7$6vq@fnnews.fnal.gov>, husby@fnal.gov (Don Husby) wrote:

>.
> 
> Errr... that would be "The advantage of ECL is the small, non saturated,
logic 
> swing and it's nearness to the very quiet ground".  ECL is inherently way less
> noisy than TTL.
> 
> The PROBLEM with ECL is it's huge power consumtion, low integration levels,
> and large price tag.
> 
> At any rate, Xilinx 3100-9 seems to compete very well in the traditionally
> ECL speed domain.  Although we haven't used it yet, we are considering
> using it (instead of ECL) to drive a 200MHz parallel optical link.

I agree 100%. My original statement was not all-encompassing. It only
addressed the aspect of interfacing between ECL and CMOS/TTL voltage
levels. In the '70s, I used to explain how ECL creates far less noise than
TTL does, and can drive terminated transmission lines which TTL and CMOS
have great difficulties with. Even today, ECL is still the silicon
technology of choice for the highest possible speed, if cost, size, and
power don't matter. 
But CMOS, inspite of its large voltage swing, is getting faster "every day".

Incidentally, we call it XC3100-09, to imply that is faster than XC3100-1. 
Read the 09 as 0.9.  
We just got faster than we anticipated when we created the numbering scheme.
A nice problem to have.
Peter Alfke
Xilinx Applications


Article: 3198
Subject: new bbs
From: somser <somser@hnet.es>
Date: Wed, 24 Apr 1996 00:47:11 +0100
Links: << >>  << T >>  << A >>
WEB (SOMSER BBS)
This BBS is working in Spain and his address is
http://www.somser.hnet.es (194.177.1.171)
Now weare in a periored of a test and going to
working every day from 20:00 to 6:00 GMT and from
10:00 to 13:00 GMT
20.000 files. 10 GB on disk. No CDROM
50 files news for day
plus 200 areas.
you are guest


WEB (SOMSER BBS)
Nuevo BBS que es un BBS, el primero que existe en España
La dirección es:
http://www.somser.hnet.es     (194.177.1.171)
Estamos en periodo de pruebas y está en funcionamiento
desde las 22:00 a las 8:00 y desde las 12:00 a las 15.00 GMT
Tenemos más de 20.000 en disco. 10GB sin CDROM
50 ficheros nuevos cada día.
Más de 200 areas diferentes.
Estais invitados, esperamos vuestra conexion.


Article: 3199
Subject: Re: Looking for FPGA Boards taking Xilinx 4000 series FPGA
From: robyn@cs.jcu.edu.au (Robyn Cheyne)
Date: 24 Apr 96 02:38:00 GMT
Links: << >>  << T >>  << A >>
In <4lh55q$f8k@mailman.xilinx> "Steve Knapp (Xilinx, Inc.)" <stevek> writes:

>"S.C.Lim" <elscl@lboro.ac.uk> wrote:
>>Hi,
>>
>>Our research group is looking into purchasing circuits boards that will
>>take one to a few Xilinx 4020 FPGA chips. These Boards are to be used
>>for circuit verifications by downloading design using Xilinx's Xact
>>cable. If the board contains multiple chips, they should all be able to
>>be programmed using a single xact cable link.
>>
>>If you have such kind of boards avaliable for sale or know anybody who
>>supplies them, please mail me at  S.C.Lim@lboro.uc.uk.

>--  I believe that Aptix offers such a board that accomodates multiple
>FPGA devices.  You can contact them via E-mail at sales@aptix.com
>and they have a Web site at http://www.aptix.com, though I didn't find
>much there.

check out the `Guess' project at Griffith University...
http://www.cit.gu.edu.au/~davida/guess.html

Guess makes use of an Aptix AP4 reconfigurable logic board. This contains 
up to 16 Xilinx 4010 Field Programmable Gate Arrays, plus a number of Aptyx 
switch chips. The switches make it possible to connect the pins of the 
Xilinx parts together, and thus the board is totally reconfigurable. 

this may be of some help...
robyn@cs.jcu.edu.au

  "  ' Maybe the knowledge is too great and maybe men are growing 
   too small,' Lee said.  ' Maybe kneeling down to atoms, they're
   becoming atom-sized in their souls. Maybe a specialist is only 
   a coward afraid to look out of his little cage. And think what
   any specialist misses - the whole world over his fence. '  " 

                                `East of Eden' by John Steinbeck.





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