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 6400

Article: 6400
Subject: memory workshop ram/rom/pld/fpga
From: fmeyer@cs.tamu.edu (Jackie Meyer)
Date: 21 May 1997 15:58:23 GMT
Links: << >>  << T >>  << A >>

The IEEE International Workshop on

    MEMORY Technology, Design, and Testing

will be held August 11-12 in San Jose.  Probably it is a 5 minute
walk for you :)  Won't you come?  Details can be found at

    <ftp://ftp.cs.tamu.edu/pub/fmeyer/service/mtdt97/abstracts.html>

Article: 6401
Subject: PhD studentship (UK)
From: Alastair Allen <eng267@abdn.ac.uk>
Date: Wed, 21 May 1997 17:59:57 +0100
Links: << >>  << T >>  << A >>
University of Aberdeen

Department of Engineering

Parallel Processing Research Group


Research Studentship (EPSRC)
===========================

An EPSRC funded research studentship is available at the Department of
Engineering, University of Aberdeen, from October 1997.  Supervision is
offered in the Parallel Processing Research Group which includes work
on DSP and imaging applications, Artificial Neural Networks,
Programmable Hardware.

The studentship provides UK/EU student fees, and standard maintenance
payments (UKP 5190) for UK students.

If you have, or expect, a good honours degree (1st or upper 2nd) in
electronic engineering, computer science, physics, or related
discipline, and would like more information, please get in touch with:

Dr Alastair R Allen
Dept of Engineering
University of Aberdeen
Aberdeen
AB24 3UE

Tel: 01224 272501
Fax: 01224 272497
Email: a.allen@abdn.ac.uk
Article: 6402
Subject: No message
From: Wilfredo Torres <w.torres-pomales@larc.nasa.gov>
Date: Wed, 21 May 1997 13:46:49 -0400
Links: << >>  << T >>  << A >>
No message
Article: 6403
Subject: Re: Cheap way to develop for FPGAs?
From: z80@dserve.com (Peter)
Date: Wed, 21 May 1997 19:28:23 GMT
Links: << >>  << T >>  << A >>
Does it support XC3010-XC3090, for which Lucent/AT&T were a 2nd
source?

If it does, then it is good value.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 6404
Subject: Gate Count Claims
From: "Rich K." <rich.katz@gsfc.nasa.gov>
Date: 21 May 1997 19:37:57 GMT
Links: << >>  << T >>  << A >>
Hi,

The recent posts on gate counting has been very interesting (and timely). 
I just received a proposal to review and would like some opinions on the
claims that are made.  The device of interest is the Atmel AT6010.  Here's
the information provided that I need to assess (actually, I have
investigated this but would like some additional opinions on this).

	. Larger than Act 1, comparable to Act 2.
		- equivalent to 20,000 gates + 6400 flip flops + RAM buffers

	. Combination of Random Logic with SRAM blocks
		- RAM buffers allow implementation of FIFO's and data buffers without
adding chips.

That's it!

Feel free to confirm or to flame [I didn't write this I don't care ;)]. 
But, I would just like an honest assessment and evaluation.  And for anyone
who has designed with this chip, actual gate counts vs. 'theoretical' gate
counts would be interesting, as in the ability to change the internal
design without changing either any pin outs or any critical path timing.

For anyone who either works for or against Atmel, please identify your
affiliation or e-mail your response to me.  If you wish to publicly post
and identify your affiliation via e-mail, that is fine, and I will hold
your affiliation in confidence.

Thanks for any information youse can provide,

rk

rich.katz@gsfc.nasa.gov

(301) 286-9705





k
Article: 6405
Subject: Re: VHDL PCI FPGA Implementation
From: jhallen@world.std.com (Joseph H Allen)
Date: Wed, 21 May 1997 20:42:17 GMT
Links: << >>  << T >>  << A >>
In article <3380c5f6.14644618@nntp.netcruiser>,
Stuart Clubb <s_clubb@netcomuk.co.uk> wrote:

I'm doing a Xilinx PCI design, so this is all very interesting.

>Xilinx's PCI solution:

>I couldn't find any publish VI characteristics data for Xilinx. Is it
>available? Does it meet the PCI spec?

They're on pages 14-9 for the XC4000E series and 14-17 for the XC3000 series
in the '96 databook.  Both are VI-curve complient, but I suspect that the
XC3000 series might not have enough GND pins.

>Document pcids.pdf page 4 indicates that in burst mode when supplying
>data, the Initiator and targets both supply data to the PCI bus at 50%
>data rate as a wait state insertion is required on every cycle.

Does anyone have any idea why this would be (for a target side PCI using
Xilinx)?  A target only PCI interface with pipelining should be able to do
this.

Also I have a question about the PCI CLK line... on PCI motherboards, can
this line be bussed or must it be driven point-to-point from a clock buffer
to each individual board?  It seems to me that if it is bussed, PCI can not
guarentee that ringing will not occur at the threshold voltage (with its
reflected wave switching).
Article: 6406
Subject: Re: VHDL or Verilog?
From: henrik@chronologic.com (Henrik Eriksson)
Date: Thu, 22 May 1997 03:08:36 GMT
Links: << >>  << T >>  << A >>
A few more criterias (that Janick forgot?) are:
* Performance of tools, such as:
    Speed
    Memory requirements
    Turn around time
* Quality(Robustness)
* Sign-off

janick@qualis.qualis.com (Janick Bergeron) wrote:

>It's a business decision.  Look at every factor EXCEPT language
>features.  Their value can only be evaluated subjectively and is the
>source of much religious conflicts.  And the feature that makes a
>language better for your next project may not be that important for
>the next one.
>
>Here are a few things to look at, in no particular order
>(except the order in which they came to mind):
>
>- Cost of tools
>- Relationship with tool vendor
>- Integration of HDL tool with existing tool set
>- Knowledge and experience of engineers
>- Engineer's subjective preference
>- Support from target and potential FPGA/ASIC vendors
>- Quality of models from vendor
>- Relationship with FPGA/ASIC vendor
>- Availability of 3rd party models for board/system simulation
>- Availability of IP blocks
>- Ease of use
>- Sign-off kit requirements
>- Customer requirements (if they purchase the final design)
>
>
>Better yet: edge your bet by picking bilingual tools!
>
>If you pick Verilog, I personally think Verilint is a must have.
>
>-- 
>Janick Bergeron       Qualis Design Corporation            Ph.: (503) 350-3663
>Director of                 PO Box 4444                    Fax: (503) 643-1583
>Technology         Beaverton, OR, USA, 97075-4444            janick@qualis.com
>  VHDL  -  Verilog  -  Synthesis  -  Modelling  -  Verification  -  Training

Article: 6407
Subject: Glitches in timing simulation of Xilinx FPGAs with Synopsys
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 21 May 1997 22:22:18 -0700
Links: << >>  << T >>  << A >>
Dear folks,

during the timing simulation with vhdlsim of a system composed of 3
Xilinx FPGA's I observe spurious glitches on an output signal with
a duration of the order of 10 ns, while the clock has a 80 ns period.
I'm wondering why I get this, as synopsys is supposed to generate
glitch free logic, right ?
Are maybe the Xilinx cells poorly modeled ? The three FPGA's are
instantiated in a top level test bench entity, and the signals generated
by the test bench are carefully timed in order to avoid hold/setup
violations on the input flip-flops.
Any idea?

thanks in advance

-Arrigo
-- 
Arrigo Benedetti		    e-mail: arrigo@vision.caltech.edu
Caltech, MS 136-93				phone: (818) 395-3695
Pasadena, CA 91125				fax:   (818) 795-8649
Article: 6408
Subject: logicores and parameterized macros
From: Martin Mason <nospam_mtmason@ix.netcom.com>
Date: Thu, 22 May 1997 00:24:26 -0700
Links: << >>  << T >>  << A >>
snip....
 
> 
> - LogiBLOX components are compiled when they are created, so there is an
> underlying EDIF, VHDL or Verilog model for each component that is
> built.  There is no need for programs like XSIMMAKE with M1; they are
> ready to simulate when they are built.
> 
> A conversion guide is shipped with the M1 software to assist users
> upgrading exsiting XBLOX designs to use LogiBLOX.
> 
> Watch the Xilinx Web Site (http://www.xilinx.com) for more information
> in the near future.
> 
> --
> David Dye
> Software Applications Engineer
> Xilinx Inc., San Jose, CA

Sorry if I blow my own trumpet, but......

Sounds a lot like Atmel's FPGAs macro generators which have been shipping for 
 about 2 years and create simulation models/schematics/symbols/hard 
layouts/deterministic timing all from one simple UI with about 50 different 
parameterisable macros availble.  Now we have linked all this good stuff in 
with synthesis too (IDS4.0); for automatic macro instanciation from VHDL or 
Verilog based synthesis tools.  If you would like more information on these 
tools e-mail fpga@atmel.com.

Martin Mason.
FPGA Apps. Atmel Corp.
Article: 6409
Subject: Re: Scientific American article on FPGAs
From: Steve Casselman <sc@vcc.com>
Date: Thu, 22 May 1997 07:45:29 GMT
Links: << >>  << T >>  << A >>
Matthias Sauer wrote:
> 
> >>>>> "Brad" == Brad Taylor <blt@emf.net> writes:
> 
>     Brad> I thought the readers of this newsgroup might want to see the
>     Brad> following article from the June97 issue of Scientific American.
>     Brad> It's kind of nice to see FPGAs (and associated researchers) getting
>     Brad> some recognition in the mainstream press. My guess is that this
>     Brad> won't be the last article. Notice that they call it "configurable
>     Brad> computing".
> 
> That's interesting, indeed. For those who might be interested in
> "Re"-configurable computing (the next generation, maybe?) I suggest to have a
> look at
> 
> http://www.comlab.ox.ac.uk/oucl/hwcomp.html
> 
> (To pick just one random URL :)
> 
>     Brad> http://www.sciam.com/0697issue/0697villasenor.html
> 
>     Brad> I'm interested in any comments about the article.  - Brad
> 
> I haven't read it thoroughly yet, but it seems that the authors completely
> forget about what is going on in Europe (see the above URL)
> 
> Cheers,
> 
> Matthias
> --
> Matthias Sauer                          Tel +44-1865-283549
> Oxford University Computing Laboratory  Fax +44-1865-273839
> Wolfson Bldg., Parks Road               email masa@comlab.ox.ac.uk
> Oxford OX1 3QD, U.K.
> URL: http://www.comlab.ox.ac.uk/oucl/users/matthias.sauer/

I also didn't see any mention of PAM or the fine work in Toronto or
Splash
or any commerical work. I believe that all the people mentioned
have DARPA contracts. When I read in the artical "the first
demonstrations 
did not occur untill a few years ago" I have to question what "a few"
means.
I think the PAM project did quite a bit work in 89 - 92 which is over 5
years ago. And algotronix had a board out in 91 I think. Just picking
some nits there. 

Anyway its great to see some exposure. In fact we advertized in the
issue.
Checkout page 133 for our ad. To see what the ad looks like visit
http://www.marshall.com

Steve Casselman
Article: 6410
Subject: Inversion in a FPGA
From: Keith Lockstone <keith.lockstone@gecm.com>
Date: 22 May 1997 08:54:32 GMT
Links: << >>  << T >>  << A >>
Has anyone any ideas on how to do a 8-bit (say) numeric inversion
inside a FPGA?  Ie 4-bit lookup plus 4-bit inperpolation.

TIA,

Keith.


Article: 6411
Subject: Re: Scientific American article on FPGAs
From: Reiner Hartenstein <hartenst@aix6.rhrk.uni-kl.de>
Date: Thu, 22 May 1997 15:02:03 +0200
Links: << >>  << T >>  << A >>
Brad Taylor wrote:
> 
> I thought the readers of this newsgroup might want to see the following
> article from the June97 issue of Scientific American.
> It's kind of nice to see FPGAs (and associated researchers) getting some
> recognition in the mainstream press. My guess is that this won't be the
> last article. Notice that they call it "configurable computing".
> 
> http://www.sciam.com/0697issue/0697villasenor.html
> 
> I'm interested in any comments about the article.
> -
> Brad


For reconfigurable computing under a machine paradigm you may like to
LOOK AT OUR WEB PAGES:  

http://xputers.informatik.uni-kl.de

Reiner
Article: 6412
Subject: Re: FPGA technology: No truth in MARKETING
From: "Rich K." <rich.katz@gsfc.nasa.gov>
Date: 22 May 1997 14:47:40 GMT
Links: << >>  << T >>  << A >>


Philip Freidin <fliptron@netcom.com> wrote in article
<fliptronEAJ09r.Ipp@netcom.com>...
> 
> I've seen some pretty stupid B*L@ S#I& in my reading of posts in various
> news groups, but this one belongs in alt.conspiracy.not.thinking.clearly

uh, perhaps a bit strong.

> 
> Kevintsmith (Of Quicklogic) responds to jwbrooks (Of Xilinx)
> 
<snip>
> 
> >  There is
> >sufficient routing wire and interconnect to easily hook up the logic
> >cells and I/Os in a device that has every logic cell used and every I/O
> >pre-placed.  The low resistance and capacitance of this type of
> >interconnect give 1,000 times less impedance (RC = 30ohms for QuickLogic
> >vs. RC=40kohms for Xilinx's SRAM interconnect).
> 
> Normally I would have just left this post go by, but the above is what 
> really set me off. ( As those who have seen me post before, you are 
> probably aware that I am not a highly opinionated person, and am only too

> happy to let bygones be bygones )

well, Quicklogic compares the resistance of different switches in a White
Paper on their WWW site.  Here they state:


Programming Technology	ViaLink 	Antifuse		Dielectric Antifuse	SRAM
Interconnect	
Silicon Area Required			1.0X			2.5X			12.5X
Typical ON Resistance			30ohms		200-500 ohms			600-800 ohms
Typical OFF Capacitance	1 femtofarad		5 femtofarads			50 femtofarads
Available Routing per Gate		1.0X			0.8X			0.24X

                  Table 3. Size and RC Characteristics of Various
Programmable Technologies 	

End direct pull from Q-Logic WWW site.


The 40 kohms sounds kind of high and it is; otherwise, parts just wouldn't
run at all through the routing network and they would have to be pretty bad
transistors.  The 600-800 ohms sounds more reasonable; perhaps some of the
sram vendors can comment on this; phil mentioned values in the 100-200 ohm
range.

One interesting parameter not included on this chart, which I feel should
be for a good trade-off, is leakage current @ maximum temperature and
voltage.  The antifuse based products have tons of antifuses, on the order
of 1 million for a 10,000 gate device, which gives them the routing power. 
On the other hand, most of the antifuses are not programmed; that is the
key point made here I believe by Q-Logic, with their low OFF capacitance,
to distinguish their Vialink from the Actel PLICE antifuse and contributes
to greater speed.  On the other hand, increasing the number of antifuses
will increase the leakage current for the amorphous silicon antifuses,
which may be a limiting factor for very large devices (esp. at MIL temps). 
Perhaps the Q-Logic people can discuss this.

<snip>

> 
> The pass transistor of the SRAM FPGA is 40Kohms (according to Kevin), and

> is therefore 1000 times worse. If this were true, then it would be 
> reasonable to expect the SRAM devices to be 1000 times slower. Last time
> I looked, muxes were often built out of pass transistors, just like the
> the muxes that make up the logic section of the QL devices. Are these
also
> 40K ohms?

i think there's some good points here, as i commented on above.  but i
don't think that the speed of the device is wholly dependent on the speed
of the switch.  that is why the architecture of say the xilinx and orca's
differ from say the actel and quicklogic ones.  the goal of the
architectures with the slower switches is to minimize the impact of their
switch technology, which does take up more room (routability) and does have
a higher resistance (speed).  i did some interesting comparisons with one
of the orca guys, comparing, if my memory is correct, a matching circuit
(like 12 bits or so) between the orca and 3200dx family; i believe that the
orca's were a bit faster.  in any event, they were both pretty good and
roughly the same.  of course, it seems that the sram-based devices, because
they use standard cmos structures (no antifuses, high voltage transistors,
etc.) have the ability to move to new, smaller processes quicker, giving
them a technology edge over their antifuse counterparts.

yes, muxes are often built out of pass transistors but the resistance of
the mux transistor (do these devices use a pass transistor or  a
transmission gate like the old cd40xxb stuff?) is less critical than the
resistance of the routing switch since obviously in a logic cell the
capacitance would be far less than a large routing track with a bunch of
loads hanging on it.

comments?

rk
Article: 6413
Subject: X3000 Timing simulation with QVPRO testbench
From: John Andreasen <john@gaia.physto.se>
Date: Thu, 22 May 1997 17:26:12 +0200
Links: << >>  << T >>  << A >>
Hi!

Have anyone tried a timing simulation in Mentors QVPRO environment?

I'm trying to do a mixed simulation with a synthesized XC3000 model
together with a VHDL testbench. Using backannotated timing information
doesn't seem to work. I can't see any delays at all.

I'm using Mentor version A3F and Xact version 5.2.1.

John

john@gaia.physto.se
Article: 6414
Subject: Re: Cadence or World Technology, or other NT vendors...
From: spp@bob.eecs.berkeley.edu
Date: 22 May 1997 16:02:45 GMT
Links: << >>  << T >>  << A >>
Richard Nuth  <nuth@col.hp.com> wrote:

>I have Simucad's SILOS III installed on my PC at home and find it to be
>quite suitable for Verilog simulations.  It runs fine under NT 3.51 and
>NT 4.0.  The simulation environment is better integrated than many I
>have seen, and you can also run "batch" mode simulations with it.

Are there simulators out there that do NOT let you run
a batch mode simulation?

If so, I'd like to know which they are so I can avoid them.

Steve
Article: 6415
Subject: Re: VHDL PCI FPGA Implementation
From: "Austin Franklin" <dark8room@ix.netcom.com>
Date: 22 May 1997 16:44:44 GMT
Links: << >>  << T >>  << A >>
> >Document pcids.pdf page 4 indicates that in burst mode when supplying
> >data, the Initiator and targets both supply data to the PCI bus at 50%
> >data rate as a wait state insertion is required on every cycle.
> 
> Does anyone have any idea why this would be (for a target side PCI using
> Xilinx)?  A target only PCI interface with pipelining should be able to
do
> this.

Target does not have this problem...or at least shouldn't in a 'well
designed' PCI interface.  I believe the problem is with master only.  It
has to do with the input timing of TRDY.  If TRDY gets pulled, the Logicore
design cannot respond in time to stop the transaction.

The design I 'use' does not have this problem for target or master...  ;-)

Austin Franklin
darkroom@ix.netcom.com


Article: 6416
Subject: Post Doctoral Fellowship Announcement
From: sharad@new-delhi.Princeton.EDU (Sharad Malik)
Date: 22 May 1997 17:50:47 GMT
Links: << >>  << T >>  << A >>
Candidates interested in pursuing a post-doctoral fellowship in the areas
of digital system design and design automation at Princeton University should
contact me via email. I am attaching a notice of the program that this is part
of. The teaching component of this program makes this an attractive opportunity
for candidates intending a subsequent academic career. 


                        PRINCETON UNIVERSITY

               POSTDOCTORAL TEACHING FELLOWS PROGRAM


Princeton University is seeking applicants for its Postdoctoral Teaching
Fellows Program.  The program is designed to provide up to three years of
stipend support to postdoctoral fellows who wish to obtain further training 
in both research and teaching. The Fellows will spend the majority of their 
time conducting research in the laboratory of a Princeton University science 
or engineering faculty member. Fellows will also gain experience in curriculum 
development, instructional laboratory design and lecturing by working closely 
with an experienced Master Teacher. The goal of the Program is to prepare 
candidates for careers in both research and teaching.

Eligible candidates should have a PhD or equivalent post-baccalaureate degree 
in one of the physical and natural sciences, or engineering. Before applying, 
applicants must first identify a research mentor from among the Princeton 
University science and engineering faculty, and obtain his or her agreement 
to act as research sponsor. A faculty member, who may or may not be the 
research mentor, will be identified for successful candidates to coordinate 
the teaching and research activities of the Fellow.  The stipend is $35,000 
per annum.  Applications are currently being accepted for Fellows to begin 
at any time during the 1997-1998 academic year. Review of applications will 
begin June 1, 1997.  Applications can be obtained by writing to:

                        The Council on Science and Technology
                           123 Lewis Thomas Laboratory
                       Princeton University, Princeton, NJ  08544

                        tel:  609-258-4316  FAX: 609-258-3345
                          email:  cprevost@pucc.princeton.edu

-- 
Sharad Malik                            sharad@ee.princeton.edu
Associate Professor                     609-258-4625
Dept. of Electrical Engineering         609-258-3745 Fax
Princeton University                    http://www.ee.princeton.edu/~sharad
Article: 6417
Subject: Re: Cheap way to develop for FPGAs?
From: "Dr. Vitit Kantabutra" <vkantabu@howland.isu.edu>
Date: Thu, 22 May 1997 13:09:53 -0700
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:
> Lucent Technologies have announced a special "Summer deal pricing" (at
> least in Europe).

Is there an ACADEMIC pricing of this available in the U.S., for Win95 or
Linux platform?  I'd be interested.  Thanks in advance.

Vitit Kantabutra
vkantabu@howland.isu.edu
Article: 6418
Subject: Re: Problem in Leonardo synthesis targetting Altera
From: Troy Garrett <troyg@wv.mentorg.com>
Date: Thu, 22 May 1997 14:33:40 -0700
Links: << >>  << T >>  << A >>
Mark,

I believe you need to use the "exemplar.lmf" file located in
the Exemplar tree ($EXEMPLAR/data/exemplar.lmf).  Specify this
file in the EDIF netlister setup in Maxplus2.  Altera is
aware that the exemplar.lmf file provided in the Maxplus2
version 7.x is obsolete, so for now specify the one shipped
by Exemplar.

Troy Garrett

Mark Sandstrom wrote:
> 
> Hi!
> 
> I'm synthesizing by Leonardo v4.03 to Altera FLEX10K CPLDs.
> If I load and resolve the FLEX10K modgens, the edif produced
> by the write altera -command contains cell referencies to
> "BUF":s.
> 
> The Altera's place and route tool Maxplus2 (v7.2) doesn't
> accept this edif and issues an error message:
> "Error: Can't find design file 'buf'".
> 
> I've been told that FLEX10K libraries that Maxplus2 uses
> don't contain an element called "BUF".
> 
> There is no problem with cell referencies to "AND2", "OR2" etc.
> 
> If I don't load and resolve the modgens in Leonardo,
> the Maxplus2 accepts the Leonardo's edif output, but the
> synthesis result is not good enough.
> 
> Is there any known solution to this problem?
> 
> I'd appreciate any information concerning this or other possible
> problems associated with Leonardo -> Altera synthesis flow.
> 
> Best regards,
> 
> Mark H. Sandstrom
Article: 6419
Subject: Any designs to avoid in FPGAs
From: Phani Putrevu <pputrevu@ececs.uc.edu>
Date: Thu, 22 May 1997 18:07:37 -0400
Links: << >>  << T >>  << A >>
Hi,

I was wondering if there are a class of circuits/systems that I should 
not implement using FPGAs. I am told that floating point units dont 
perform well when implemented using FPGAs. In fact a multiplier that I
had implemented required 200ns (16 bit). Present day CPUs have much 
better FPUs/ALUs. 

There was some discussion abt implementing comparator using FPGAs, and
some suggested use CPLDs for combinational logic. Are there any other
thumb rules as to when to go for an FPGA and when not to.

This becomes important when you are considering co-design and you want
to decide if a function is to be executed in h/w or s/w. I have seen
systems where this is specified as a part of the input code.

Thanks a lot.

Phani
------------------------------------------------------------------------
     Phani K Putrevu                      384 Probasco Street  #14
     MS - Comp  Engg                      Cincinnati    OH   45220
     University of Cincinnati             Ph : 513-281 1154  (res)
     email: pputrevu@ececs.uc.edu              513-556-0904  (lab)
     URL : http://www.ececs.uc.edu/~pputrevu
------------------------------------------------------------------------
Article: 6420
Subject: Re: Configurable Computing
From: VCC <info@vcc.com>
Date: Thu, 22 May 1997 23:32:18 GMT
Links: << >>  << T >>  << A >>
Yes this is pretty much the same package. We could not quite call the 
package Trianus for marketing reasons:) We are fixing the interface
to Lola(Trianus) so it will have the look and feel of windows on the
pc or mac. 

You know there are certain times in history when an effort by a 
small group can make a big difference. What is need is a language
that goes from operating systems and high level languages right
down to programming hardware. There are currently attempts to have
java and C++ be these languages but they are frozen by standards
and red tape.  Today as we speak Lola is the only language that
is designed just for programming FPGAs. VHDL and verilog where
designed for different purposes (none include placement for example).
Also Lola compiles very fast because of the common data structure.

A language that is designed to program both configurable
hardware and normal CPUs will help change the world. Lola
is not quite the language but it is a damm go start.


Steve Casselman, President
Virtual Computer Corporation
See our distributors page
http://www.marshall.com




mcintosh@vima.austin.tx.us wrote:
> 
> Recent articles in Comp.Lang.Oberon have asked variously
> what Prof. Dr. Wirth is doing, why no high visibility Oberon projects
> exist, and whether advertising would help the Oberon community.
> 
> The June '97 Scientific American has a Xilinx FPGA on the cover and
> an article about Configurable Computing on p. 66.  In addition, in a
> full page ad on p. 133, the Xilinx XC6200 development package is
> mentioned, along with the Lola language and Niklaus Wirth.
> 
>  A prof. John Koza, Stanford, is quoted as a user.
> 
>  The Web index on p. 61 does not mention any link to any apparant
>  connection to the product, an unfortunate omission.
> 
> The WWW page given in the ad does not lead to a page describing
> the product.  However, some searching on altavista gives
>  http://www.vcc.com/ as a url for the Virtual Computer Corporation.
> 
> It is tempting to assume that the Trianus package announced on
> approximately Dec 23, '96 is identically the software being distributed
> with the H.O.T. Works product.  Some reference is made to a Xilinx
> reference design, which may imply that Xilinx or another party does
> or could second source the board itself.
Article: 6421
Subject: test
From: PG Williams <***PGW@infinet.com>
Date: Thu, 22 May 1997 17:06:28 -0700
Links: << >>  << T >>  << A >>
test
Article: 6422
Subject: Cypress WARP question
From: "Stephen P. Pope" <spp@rahul.net>
Date: 23 May 1997 01:04:44 GMT
Links: << >>  << T >>  << A >>
There is a Cypress product, on CD, entitled "Cypress WARP Version 4.0".
The current Cypress databook does not to describe a product
by this exact name; the products listed there are "Warp2", 
"Warp2+", "Warp3", and "Warp3 Pro Series Built-in".

Does "WARP Version 4.0" correspond to any of these?

Thanks.
Steve
Article: 6423
Subject: Re: Glitches in timing simulation of Xilinx FPGAs with Synopsys
From: aca@ix.netcom.com(ACA)
Date: 23 May 1997 05:43:15 GMT
Links: << >>  << T >>  << A >>
In <q0raf0gjxx.fsf@vision.caltech.edu> Arrigo Benedetti
<arrigo@vision.caltech.edu> writes: 
>
>Dear folks,
>
>during the timing simulation with vhdlsim of a system composed of 3
>Xilinx FPGA's I observe spurious glitches on an output signal with
>a duration of the order of 10 ns, while the clock has a 80 ns period.
>I'm wondering why I get this, as synopsys is supposed to generate
>glitch free logic, right ?
>Are maybe the Xilinx cells poorly modeled ? The three FPGA's are
>instantiated in a top level test bench entity, and the signals
generated
>by the test bench are carefully timed in order to avoid hold/setup
>violations on the input flip-flops.
>Any idea?
>
>thanks in advance
>
>-Arrigo
>-- 
>Arrigo Benedetti		    e-mail: arrigo@vision.caltech.edu
>Caltech, MS 136-93				phone: (818) 395-3695
>Pasadena, CA 91125				fax:   (818) 795-8649

Maybe it's difficult to say without look at your design, but I would
say to register your outputs may fix the glithes.

Alfred Chang
aca@ix.netcom.com
Article: 6424
Subject: Re: Q: Leonardo, any pros/cons using this ?
From: Larice@vidisys.ccn.de (Larice Robert)
Date: 23 May 1997 07:47:23 GMT
Links: << >>  << T >>  << A >>
Daniel Roganti (ragman@euronet.nl) wrote:
: Anyone with some advice about using leonardo?
: Any pros/cons regarding this development software ?
: thanks
: 
: +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_
: Name:  Daniel Roganti                            
: Email work : daniel@betronic.nl
: Email home : ragman@euronet.nl
: Smail: Oud Wulvenlaan 35-2, 3523XS Utrecht, Netherlands,Europe
: WWW:   http://www.euronet.nl/users/ragman
: Back home: Margate, Florida            Hometown : Elmont, New York
: ...exploring cyberspace before it runs out of  space...
: +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_
: 


We have recently bought Exemplars Leonardo 4.0.3 for Linux.
We are doing FPGA synthesis (mainly Xilinx) with it.
We considered:
  Synplify from synplicity
  FGGA Express from Synopsis
  Galileo and Leonardo from Exemplar
Synplify and FGPA express are Windows applications in its ugly sense.
  Solely PushButton Based.
  Solely Interactive.
  Unable to be integrated into more complex Design Flows.
  No Command-Line at all.
But they are fast. (Till now we have no speed problems, even with leonardo,
even with a 133 Pentium)
Synplify has the advantage that you get both VHDL and Verilog together.
For Exemplar and FPGA Express you have to decide for VHDL or Verilog.
Or you have to pay twice price. For Synplify,FPGA Express and Galileo
you have to decide which target Devices you want. The more Devices the
more price. For Leonardo you always get every Device. So you have the
possibility to consider another FPGA manufacturer without to much initial
overhead.
Leonardo cant be compared with Synplify Express and Galileo. It is a
optimisation system which gives you access to its functionality via
  1) a synthesis tool which is controlled by a built in tcl interpreter.
     The so called program "elsyn".
  2) a tcl/tk interactive GUI interface. The so called program "leonardo".
     this GUI starts a graphical tk session, and feeds commands to a
     parallel running "elsyn"
     This is very effective, since you can learn interactively from the GUI
     what commands have to be fed to elsyn to do a specific job.
     Once you have learned what has to be done, you can write it together
     to a tcl script and send it to elsyn directly.
The functionality which elsyn exposes to you gives you very detailed control
of the synthesis. Contrary for Synplify, FPGA-express and galileo the job
is pretty fixed.

leonardo is the most expensive of these tools (aprox 16000$). But in my
opinion its capabilities go far beyond what you can do with the other tools.

Due to Price, and due to our inexperience concerning HDL tools our decision
around Jan 97 was to go for synplicity. At the very last moment Exemplar
announced Linux support for Leonardo, and I investigated a demo installation
of Leonardo. I was such impressed that we have bought it around April.

Note:
  The leonardo Price for Linux is the same as for Windows.
  The Price for Sun and HPUX is aprox twice as high.
  So with Linux you can use this tool on a full fledged Unix
  (on a cheap intel based PC) for the same price as the Windows version.

Larice


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