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 200

Article: 200
Subject: Re: Lattice ISP software: really bad or just different?
From: mcgaugh@eng.iac.honeywell.com (Paul McGaugh)
Date: 19 Sep 1994 21:16:15 GMT
Links: << >>  << T >>  << A >>
Tim Schneider (schneider@hwcae.Honeywell.COM) wrote:

: Here are the details from one of the engineers at our facility who
: attempted to use the Lattice design kit... This is what I referred to
: in my original post.


: From: "Paul McGaugh" <mcgaugh@eng.iac.honeywell.com>
: To: schneider
: Date: Thu, 15 Sep 1994 18:39:20 -0600
: Subject: Re: Forwarded mail [Lattice ISP software:  really bad or just different?]


: > Can someone tell me what the real problem is?  Is the Lattice software
: > really cumbersome or is it annoying becuase works differently and uses
: > different conventions than more standard PLD software?
: >
: > Lattice's "Starter Kit" looks like a very effective way to get started
: > with PLD's.  If the software is really bad I may look elsewhere but if it
: > is just "different" then there really isn't a problem.  I have no old
: > habits to unlearn.

<<<deletia>>>

: care) how each signal is routed between each "macrocell".  Here's where the
: Lattice software becomes extremely tedious.  It expects the designer to write
: seperate equation sets for each of the macrocells (like on the order of 32 or
: 64 or 128 macrocells).  Essentially, the designer has to partition his design
: into tiny bits that will fit into the macrocell.  If the design changes at all,
: the designer will have to do the partitioning all over again... this is no
: small task, even for the small CPLDS.  So, unless your budget is paramount and
: time is unlimited the Lattice software leaves much to be desired.


In the previous post I would like to add that only the Lattice _Stand_Alone_ 
software is considered and in no way does the software relate to the
quality/features of the Lattice PLDs themselves.  I think Lattice has some
of the finest devices available. Their isp line has some advantages that you
just can't get with any other device on the market and I don't work for Lattice
and I didn't get paid to say that. :-)
However, the lack of software development tools makes it impossible to realize
a singular process flow and seamless integration with the Mentor/HP platform.
Even though Lattice advertises "Minc" support in their data books, it doesn't
actually exist???... yet?  So, if your on a Sun or PC you need to get a copy
of something like ABEL from DATA I/O and the Lattice fitter in order to have
a tool that you can really design with.

p.mcgaugh@ieee.org             ! (602)789-5256
--
"So far as the laws of mathematics apply to reality, they
are not certain. So far as they are certain, they do not
apply to reality." - Albert Einstein
--
[I speak only for myself]
      
        


Article: 201
Subject: Re: PLD for async state machine?
From: marting@hpqtdla.sqf.hp.com (Martin Curran-Gray)
Date: Tue, 20 Sep 1994 06:49:44 GMT
Links: << >>  << T >>  << A >>
Jim Tompkins (tompkins@appliedmicro.ns.ca) wrote:
: 
:    I'm trying to implement an asynchronous state machine in
: a PLD.  Anyone know of a good device for doing so?  I need
: a small number of flip-flops with true asynchronous sets
: and resets.
: 
:    Any suggestions greatly appreciated.
: 

Cypress PLDC20RA10, or any 20RA10 device?

10 FlipFlops, 10 Inputs , 1 dedicated preload input


Databook claims fully asynchronous control of register set, reset and clock


			Martin


Article: 202
Subject: Re: Partly reconfigurable FPGAs
From: wirthlim@fpga.ee.byu.edu (Michael J. Wirthlin)
Date: 20 Sep 1994 08:44:10 -0600
Links: << >>  << T >>  << A >>

In article <CwDvpJ.1xI@nntpa.cb.att.com>, wao@antares (W. Oswald) writes:
|> Gerrit Telkamp (telkamp@eis.cs.tu-bs.de) wrote:
|> 
|> All of the AT&T ORCA(tm) series fpga's can be partially or completely
|> reconfigured on the fly. Capacity : 3,000 - 26,000 gates
|> 
|> --
|> My views are my own!
|> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
|> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
|> _/_/ Bill                                       _/_/
|> _/_/    __      _  _  __                  _     _/_/
|> _/_/   /  )    // // / ')                //   / _/_/
|> _/_/  /--<  o // // /  / _   , , , __.  // __/  _/_/
|> _/_/ /___/_<_</_</ (__/ /_)_(_(_/_(_/|_</_(_/_  _/_/
|> _/_/                                            _/_/
|> _/_/ w.a.oswald@att.com                         _/_/
|> _/_/ billatt@aol.com                            _/_/
|> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
|> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Last year, I was told by an ORCA sales rep. that the ORCA part did not 
support partial reconfiguration. I have pulled out my old copy of the 
"Feb. 1993 ORCA Advance Data Sheet" and could find very little information 
on this feature. Could anybody provide some more detail on the "partial 
reconfigurable" feature of the device?

-- 
Michael J. Wirthlin
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-7206
-- 
Michael J. Wirthlin
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-7206


Article: 203
Subject: Re: Lattice ISP software: really bad or just different?
From: bbutler@netcom.com (Bryan Butler)
Date: Tue, 20 Sep 1994 21:30:55 GMT
Links: << >>  << T >>  << A >>
Skrodzki Stefan (skrodzki@t500m0.telematik.informatik.uni-karlsruhe.de) wrote:

> > (believe me,
> > there are still designers out there who want to do everything manually).

> There are still designers out there who want to have first _results_ and
> then perhaps improve them manually.

> The bad thing is that the isp chips are IMHO a very good choice in price and 
> functionality but _not_ with that gruel software.

> So, come on You people at Lattice. Take a look at other low-cost design tools
> (look at ftp.intel.com :-) an change the pds from a funny double-clicking-
> memmory-munging windows programm to a powerful development tool. Many people
> would thank you for this with buying the ips chips!

I haven't used the Lattice software, so I don't understand how the manual
partitioning is different than what the Intel software requires?

> I think one of the reasons why intel flexlogic becomes more and more respect
> the recent time is their development tool!

I don't consider the Intel tools to be very good, but at least they're free.
I always thought it was counter-productive to charge for software that is only
good for one vendors chips. This is the primary reason I haven't used Lattice
parts. If they would give away their software, I might try them.

--
-------
Bryan Butler
bbutler@netcom.com


Article: 204
Subject: Postings sent as mail ???--------------
From: schneider@eng.iac.honeywell.com
Date: 21 Sep 1994 11:40:03 -0500
Links: << >>  << T >>  << A >>
** In article <leejaCwCw3J.4KG@netcom.com>, leeja@netcom.com (Leeja) writes:

  Leeja> How would one go about posting to the group if this method were
  Leeja> possible?

send your post to...

comp-arch-fpga@cs.utexas.edu  (mail to news gateway)

 -tim



  \                      tim schneider
 o/\_            schneider@eng.iac.honeywell.com
<\__,\              602.863.5656  Phoenix, AZ
 ">   |
  `   |         Sometimes you're the windshield...
       \            Somtimes you're the bug.  
        \










Article: 205
Subject: Mail reflector
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Wed, 21 Sep 1994 19:20:05 GMT
Links: << >>  << T >>  << A >>
SRC has instituted a mail reflector of comp.arch.fpga intended for
people who either don't receive this newsgroup or don't read news
regularly.  It is a mailing list that digests the articles on
comp.arch.fpga daily and sends them out via email to list members.
There is also a submission address that will post email messages to
the newsgroup.

To get subscription information, send a message to:

	comp-arch-fpga-request@super.org

and you will receive a message with all the subscription information.


------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org



Article: 206
Subject: C.A.F. WWW page (aperiodic reminder)
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Wed, 21 Sep 1994 19:32:45 GMT
Links: << >>  << T >>  << A >>
The IDA Supercomputing Research Center (SRC) maintains a World Wide
Web page for the comp.arch.fpga newsgroup that contains:

1) The group charter;

2) An archive of posted messages with various retrieval mechanisms;

3) A list of upcoming events of interest to the custom computing
community; 

4) Pointers to organizations engaged in FPGA based computing research;

5) Several other interesting links.

This page can be found at:

	ftp://ftp.super.org/pub/www/FPGA/caf.html

Note that you must specify "ftp" protocol, as we're not running HTPD
yet.

This page is still very much under construction, so any comments or
additions are welcome.  We would especially like to solicit
contributions to a bibliography and a FAQ list.

-jeff

------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org



Article: 207
Subject: Software costs (was Re: Lattice ISP software)
From: rvireday@pldote.intel.com (Richard Vireday)
Date: 21 Sep 1994 20:04:40 GMT
Links: << >>  << T >>  << A >>
In article G26@netcom.com, bbutler@netcom.com (Bryan Butler) writes:
>I always thought it was counter-productive to charge for software that is only
>good for one vendors chips

Well Bryan, when it can cost any company over 1 million dollars
to get the software written for their hottest new device, you had better 
do your part and buy a lot of chips to amoritise the cost.

If a typical PLD/FPGA sells only 10,000 units in the first year
of introduction (this is an industry average, ref. Dataquest), then you can tell
your suppliers to tack on an extra $20 onto each device you buy!
(Just assume there are four other people out there buying it too! :-)

--Richard Vireday
Formerly of Intels PLD & FPGA Business Unit 





Article: 208
Subject: Re: Software costs (was Re: Lattice ISP software)
From: npomponi@cmdl.gatech.edu (Nick Pomponio)
Date: 21 Sep 1994 20:58:50 GMT
Links: << >>  << T >>  << A >>
rvireday@pldote.intel.com (Richard Vireday) writes:

+In article G26@netcom.com, bbutler@netcom.com (Bryan Butler) writes:
+>I always thought it was counter-productive to charge for software that is only
+>good for one vendors chips

+Well Bryan, when it can cost any company over 1 million dollars
+to get the software written for their hottest new device, you had better 
+do your part and buy a lot of chips to amoritise the cost.

+If a typical PLD/FPGA sells only 10,000 units in the first year
+of introduction (this is an industry average, ref. Dataquest), then you can tell
+your suppliers to tack on an extra $20 onto each device you buy!
+(Just assume there are four other people out there buying it too! :-)

The $1M price tag may be credible for a company to initially develop a
software system (GUI, routing, simulation, etc.), but the incremental cost
for adding new chips shouldn't be nearly that high.  I would be very
surprised if Data I/O or Logical Devices spent $1M for each device they
add to their extensive Abel/CUPL libraries.

+--Richard Vireday
+Formerly of Intels PLD & FPGA Business Unit 





Article: 209
Subject: Brust Mode (For the SBus)
From: sc@vcc.com (Steve Casselman)
Date: Thu, 22 Sep 1994 02:17:06 GMT
Links: << >>  << T >>  << A >>
I'm tring to get the sun (os 4.3.2) to give a SBus
card I made to give me burst data. I can get it to
give me double data transfers by casting everything
as double. Right now I just do a mmap simple thing.
Does anyone know how (with just mmap) I can get the
Sun to give me bursts? There is a driver for solaris 2
that has a real mmap loadable driver but I'm not up on
solaris 2, is there any 4.3.2 driver out there like that?


Thanks In Advance


Steve Casselman
Virtual Computer
sc@vcc.com




Article: 210
Subject: Re: PLD for async state machine?
From: holger@ira.uka.de (Holger Hellmuth)
Date: Thu, 22 Sep 1994 10:12:44 GMT
Links: << >>  << T >>  << A >>
tompkins@appliedmicro.ns.ca (Jim Tompkins) writes:

>Hi,

>   I'm trying to implement an asynchronous state machine in
>a PLD.  Anyone know of a good device for doing so?  I need
>a small number of flip-flops with true asynchronous sets
>and resets.

>   Any suggestions greatly appreciated.

AMD: 

PALCE20RA10	24pin, 10 D-type Flipflops, Clock, asynch Preset and Reset with one 
		Product term each
PALCE29MA16	as above, but 16 Flipflops

TI:

nothing

Cypress:

PLDC20RA10	seems to be identical to the AMD 20RA10

CY7C331		28pin, 12 D-type FFs, 12 Feedback FF (sort of buried), Clock, Reset and 
		Preset with one Product term each

If you can't get these devices or don't have a programmer for them, and need 4 or fewer
Flipflops, there may be an easier way:
Use standard TTL flipflops and connect them to a combinatorial PLD. That way you still
have the flexibility of PLDs and the asynchronicity. Ok, it's only a last resort.
	
								Holger.

-- 

Holger Hellmuth at Uni Karlsruhe
<hellmuth@ira.uka.de>


Article: 211
Subject: Re: Software costs (was Re: Lattice ISP softw
From: rvireday@pldote.intel.com (Richard Vireday)
Date: 22 Sep 1994 21:58:27 GMT
Links: << >>  << T >>  << A >>
In article ldi@mordred.gatech.edu, npomponi@cmdl.gatech.edu (Nick Pomponio) writes:
>The $1M price tag may be credible for a company to initially develop a
>software system (GUI, routing, simulation, etc.), but the incremental cost
>for adding new chips shouldn't be nearly that high.  I would be very
>surprised if Data I/O or Logical Devices spent $1M for each device they
>add to their extensive Abel/CUPL libraries.

No, they don't.   Although they typically ask for a good chunk of
change to do the devices, even to incorporate the vendors software.
And, they are almost always have a delay of about one year.

Costs are a large touchy issue, and I was just taking a short cut
based on typical PLD/FPGA industry trends.

--Richard Vireday





Article: 212
Subject: Re: really good
From: david@fpga.demon.co.uk (David Pashley)
Date: Fri, 23 Sep 1994 11:31:21 +0000
Links: << >>  << T >>  << A >>
Trevor Hall of ICL writes:

"In article <SCHNEIDER.94Sep15180618@ms13.hwcae.az.Honeywell.COM>,
"Tim Schneider <schneider@eng.iac.honeywell.com> wrote:
">
">Here are the details from one of the engineers at our facility who
">attempted to use the Lattice design kit... This is what I referred to
">in my original post.
">
">The Lattice software IS really bad compared with most other packages. (All
">other packages as far as I know.)  Here's the deal.
"
...snip...
"> easy as utilizing the AMD mach devices in our PLDSII Minc/Mentor
" environment.)
"
"I am currently using ispLSI3256 devices (approx 80% pin and GLB utilazation).
"My experience so far has shown the Lattice parts to be far superior to AMD mach," where
"fitting and then re-fitting with the pins fixed is concerned. I have used both
" MINC and
"PALASM to fit AMD parts and quite honestly it was an unpleasant experience.
"
"I am using MINC as a front end, with a MINC to ABEL pla bridge to the Lattice
" fitter.
"This bridge was co-developed by ourseleves and Lattice UK (who did most of the
" work I may add). As this bridge is still under development I doubt that it
" will be freely
"available yet.
"
"As for the grumblings I have seen here about the cost of PDS+, well it cost us
" the 
"grand sum of 600 uk pounds. That is a lot less than the approx. 2K pounds MINC
" will
"charge for a their own Lattice fitter (if and when they get round to doing it).
"
"
If Paul McGaugh wants to praise his MINC s/w and AMD devices, isn't 
that OK?  I don't think your defence  of the Lattice s/w is enhanced by 
saying that you have not prospered with this popular combination. 
After all, he's using the same MINC and the same MACH as you! 

I'd like to point out that neither MINC, nor any other PLD-
tool supplier is to my knowledge "getting round" to writing a 
fitter, since it is Lattice's preference that tool vendors use the 
Lattice fitter rather than writing their own. 

Since Lattice have chosen PLA format as the input to their fitter, 
the work-around you describe is right solution, and will also be 
available from MINC soon. 

MINC will not charge 2K Pounds for this, and has never charged its 
PC-based customers anything like 2K even for a full family of 
fitters (e.g. MACH100 series, 200series and 400 series - price just 
over 1K for the lot). 

The implication is therefore totally unfair. 

David Pashley
Direct Insight Ltd 
*The independent CPLD/FPGA experts*
+44 280 700262



Article: 213
Subject: Re: PLD for async state machine?
From: david@fpga.demon.co.uk (David Pashley)
Date: Fri, 23 Sep 1994 11:47:13 +0000
Links: << >>  << T >>  << A >>
Jim Tompkins writes:

"Hi,
"
"   I'm trying to implement an asynchronous state machine in
"a PLD.  Anyone know of a good device for doing so?  I need
"a small number of flip-flops with true asynchronous sets
"and resets.
"
"   Any suggestions greatly appreciated.
"
Depends what you mean by small! Here are some suggestions (smallest 
first)

20RA10 (AMD and others)  10 FFs
29MA16 (AMD)             16 FFs
EP310 - EP1810 (Altera)  8 to 48 FFs
MACH215 (AMD)            64 FFs

Hope that helps

David Pashley
Direct Insight Ltd
*The independent CPLD/FPGA experts*
+44 280 700262


Article: 214
Subject: Reconfigurable FPGAs
From: martin@atmel.com (Martin Mason (408) 436 4178)
Date: Fri, 23 Sep 1994 17:39:43 GMT
Links: << >>  << T >>  << A >>
Gerrit Telkamp (telkamp@eis.cs.tu-bs.de) wrote:
: Two or three weeks ago someone looked for partly reconfigurable FPGAs
: (unfortunately I can't remember that posting exactly)

: I found FPGAs in the new ATMEL programmable logic data book, which can be
: partly reconfigurated (AT 6000 series). Capacity : 2.000 - 10.000 gates.

: Gerrit

	As Gerrit rightly points out Atmel has a family of reconfigurable FPGAs.  The parts can be fully or partially reconfigured (down to the individual cell level).  The areas of the FPGA not being reconfigured will continue to function as normal whilst new areas are being reconfigured.  Atmel calls this C

o supported via Atmel FPGA engineering under a non-disclosure aggrement.
	For further information on the Atmel's CacheLogic FPGAs you can snail-mail Atmel at:

	FPGA Literature Request
	Atmel Corp.
	2125, O'Nel Drive
	San Jose
	CA 95131
or call :
	(800) 292 8635 in the USA
	
or e-mail 
	FPGA@ATMEL.COM with you name, address and phone number.

Martin Mason
FPGA Applications Engineer
Atmel Corp (San Jose)
e-mail: martin@atmel.com


Article: 215
Subject: Xilinx 4000
From: marting@hpqtdla.sqf.hp.com (Martin Curran-Gray)
Date: Mon, 26 Sep 1994 12:13:05 GMT
Links: << >>  << T >>  << A >>
Hi All,
       After several years of 3000 Series Xilinx work, I'm considering a 4000
device because of it's internal RAM.

I was wondering if anyone with experience of the 4000 RAM could give some hints,
or just some general 4000 best practices??


If people prefer to mail direct rather than post to the newsgroup, I'll post a
summary of what I receive.


 			Thanks


				Martin Curran-Gray

				marting@hpsqf.sqf.hp.com


				Queensferry Telecom Operation
				Hewlett Packard Ltd


Article: 216
Subject: Exemplar CORE experiences?
From: koch@eis.cs.tu-bs.de (Andreas Koch)
Date: Mon, 26 Sep 1994 14:02:03 GMT
Links: << >>  << T >>  << A >>
We would be interested in hearing about any experiences with
Exemplar's CORE/TopDown+ synthesis tool. It seems somewhat
less hardware-hungry than the Synopsys suite. While our primary
target would be Xilinx 4000 FPGAs, comments regarding other
technologies (eg. standard-cell ASICs like ES2) would be
useful.

Thanks,
	Andreas Koch
-- 
Andreas Koch                                   Email  : koch@eis.cs.tu-bs.de
Institut f"ur theoretische Informatik          Phone  : x49-531-391-2384
Abteilung Entwurf Integrierter Schaltungen     Phax   : x49-531-391-5840
Gaussstr. 11, D-38106 Braunschweig, Germany    Telex  : 95 25 26


Article: 217
Subject: XC1765DPD8C
From: txw@festival.ed.ac.uk (Tomas Whitlock)
Date: Mon, 26 Sep 1994 14:43:01 GMT
Links: << >>  << T >>  << A >>
Hello,

I have a problem with the XC1765 serial PROM. We are using these with
Xilinx FPGA's, and we wish to program these PROM's with an Intel Hex format
file. Unfortunately, the programmer we have access to does not accept this
format for these devices. We are told that we must convert the file to
a jedec (.jed) file. So: does anyone know of a program that could fulfill
such a function? The intel hex file is, of course, not specific to any
particular device, whereas a .jed file is.

I'm sure someone has already posted this, but I am new to this newsgroup.
Is there a Xilinx FTP site with public domain software anywhere? Its
address would be much appreciated.

Thank you kindly,

Tomas Whitlock
Alpha Data Parallel Systems Ltd.

ps. please ignore the From: field of this posting! Please e-mail any
information to tw@alphadata.co.uk


Article: 218
Subject: Re: Xilinx 4000
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 26 Sep 1994 17:28:28 GMT
Links: << >>  << T >>  << A >>
In article marting@hpqtdla.sqf.hp.com (Martin Curran-Gray) writes:

>After several years of 3000 Series Xilinx work, I'm considering a 4000
>device because of it's internal RAM.
>
>I was wondering if anyone with experience of the 4000 RAM could give
>some hints, or just some general 4000 best practices??
>
>If people prefer to mail direct rather than post to the newsgroup,
>I'll post a summary of what I receive.

I've done numerous Xilinx 3K and 4K designs, and I've learned many
lessons at great cost (the true mark of a *real* FPGA designer!).

1.  As with 3K parts, you will live happier and slip less schedule
    if you don't use more than 75% of the available gates.  I've done
    3K designs with 99%+ utilisation, but with similar design
    architectures in 4K, routing delays go ballistic above 75%
    utilisation.

2.  Don't use the -4 (fastest) speed grade.  Design to the -5 speed
    grade (or slower), and then specify -4 speed grade (or whatever
    the next fastest speed grade is) parts for production.

3.  As you approach the practical limits of your chosen technology,
    your design time increases hyperbolically.  The technology limits
    are the hyperbolic assymptotes at which design time is infinite.
    This is a general rule for all ASIC design technologies.  The limits
    are different for 4K than they are for 3K (see #1 above).

4.  If you are clocking (reading/writing) the on-chip RAM at full speed
    (1 write per clock cycle, with or without a read cycle in the same
    clock cycle), you *will* need to use the system clock as the RAM
    write pulse.  See the Xilinx RAM app notes for details.

    What isn't spelled out is that there are two global clock runs which
    are useable for the RAM WE signal.  Any of the BUFGS buffers can
    drive either of these two runs, but each BUFGP has connectivity to
    only one of the clock runs.  So two of the four BUFGPs (and their
    dedicated clock pads) are useless for master clock purposes in this
    case.  Make sure you choose your clock buffer and clock pin wisely.

    I don't think the BUFGS/BUFGP delay differences are well
    characterised; they certainly aren't described well in the data books.
    You will probably be happier if you stick to the BUFGPs for all
    clock distribution where clock skew is a concern.  There are some at
    Xilinx who would debate this contention.  I have personal reasons
    for this conviction which relate to using the on-chip RAM.

5.  If you use the 4KH (High I/O count) devices, there are some copies
    of databooks with erroneous pinout diagrams.  Contact Xilinx directly
    for lastest and greatest pinout diagram, just to be safe.

6.  Be very conservative about thermal design.  There are some at Xilinx
    who still don't believe that FPGAs "burn" significant power.  Wrong.
    Many of my designs are 27 MHz, and one design dissipates 2.5W while
    only half the "gates" are operating at full clock rate.  There are
    no solid power estimation tools from Xilinx, so if you are running
    at 10 MHz or higher you should be aware of package thermal
    characteristics and system cooling considerations.

    Remember, all CMOS devices slow down at elevated temperatures.
    Xilinx FPGAs are no exception.  This is a speed issue, not a
    Xilinx 4K reliability issue.  Xilinx 4K has good MTBF up to 150 C
    junction temperature (check it yourself).

7.  Be careful about using both clock edges with tight timing tolerances.
    The clock buffers have TTL thresholds and asymmetric rise/fall times
    internally.  So 50% duty cycle clock waveforms externally don't
    necessarily translate into 50% duty cycle square waves internally.
    If you clock on both clock edges, you probably should provide at least
    4 nS of timing margin.

8.  Don't be lulled by a batch of Xilinx FPGAs with excellent timing
    margins.  All FPGA vendors, including Xilinx, are aggressively pursuing
    smaller and smaller fab processes.  As the distribution of their
    parts with respect to timing performance changes, and as their order
    demand for different speed grades shift, you may get parts which
    greatly exceed minimum timing specs.  The next month you may get parts
    which aren't quite so fast.   So don't get over-confident from the
    excellent yield and/or margins on the first 50 boards.


Any/all of these points may be pertinent to your design, or perhaps not.
These observations may be irrelevant for succeeding generations of
Xilinx process variations, products, etc.  In other words, your mileage
*will* vary !

I've designed with 4005a, 4010, and 4013; and my colleagues have designed
with 4005h.  These are the words of wisdom which we share amongst
ourselves.

I suspect that these observations apply to ASICs and FPGAs in general, and
not just to Xilinx products, to a varying extent.  My experience is with
Xilinx devices, however, and you can draw some conclusions from the fact
that I've done many Xilinx designs.


Bob Elkind, Tektronix TV Products

I speak for myself, and not for Tektronix.


Article: 219
Subject: Re: Lattice ISP software: really good
From: mcgaugh@eng.iac.honeywell.com (Paul McGaugh)
Date: 26 Sep 1994 18:05:00 GMT
Links: << >>  << T >>  << A >>
Trevor Hall (trev@ss11.wg.icl.co.uk) wrote:
: In article <SCHNEIDER.94Sep15180618@ms13.hwcae.az.Honeywell.COM>,
: Tim Schneider <schneider@eng.iac.honeywell.com> wrote:
: >
: >The Lattice software IS really bad compared with most other packages. (All
: >other packages as far as I know.)  Here's the deal.
: ...
: >(The point of most software packages is to partition the design.  With Lattice
: > software, YOU are the partitioner, that's the problem, wish it were as

: Not true, auto partitioning is included with PDS+

Yes it IS true.  The original question was about Lattice's starter kit with _no_
Abel or Minc front end.  This stand alone starter package does not partition.  We
were not talking about pDS+, we were talking about pDS.
Sure, if you have an Abel or Minc connection you can have Lattice devices 
auto partitioned. That was not the question.

: My experience so far has shown the Lattice parts to be far superior to AMD mach, where
: fitting and then re-fitting with the pins fixed is concerned. I have used both MINC and
: PALASM to fit AMD parts and quite honestly it was an unpleasant experience.

I never suggested that AMD parts were better for re-fitting design changes.  In
fact, I would have to agree with you that re-fitting AMD MACH devices is a
very frustrating and unpleasent experience.  I only meant that AMD's software has
a MUCH better integration strategy with our current tool set and platform. I am
using a Mentor/Minc front end and Lattice does not offer anything to us, at
this time, that will hook in to Minc.  (I don't mean to suggest that Lattice
devices are somehow inferior, I just wish they would get off the pot and get
going with Minc.  Some of us don't have a preliminary Abel to Minc bridge.)

--
Paul McGaugh                   ! Honeywell IAC 
Electronics Engineer           ! Phoenix, Arizona
p.mcgaugh@ieee.org             ! (602)789-5256
--
"So far as the laws of mathematics apply to reality, they
are not certain. So far as they are certain, they do not
apply to reality." - Albert Einstein
--
[I speak only for myself]
      
        


Article: 220
Subject: Re: really good
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: Tue, 27 Sep 1994 05:44:15 GMT
Links: << >>  << T >>  << A >>
david@fpga.demon.co.uk (David Pashley) writes :-

>If Paul McGaugh wants to praise his MINC s/w and AMD devices, isn't 
>that OK?  I don't think your defence  of the Lattice s/w is enhanced by 
>saying that you have not prospered with this popular combination. 
>After all, he's using the same MINC and the same MACH as you! 
>
>I'd like to point out that neither MINC, nor any other PLD-
>tool supplier is to my knowledge "getting round" to writing a 
>fitter, since it is Lattice's preference that tool vendors use the 
>Lattice fitter rather than writing their own. 
>
>Since Lattice have chosen PLA format as the input to their fitter, 
>the work-around you describe is right solution, and will also be 
>available from MINC soon. 
>
>MINC will not charge 2K Pounds for this, and has never charged its 
>PC-based customers anything like 2K even for a full family of 
>fitters (e.g. MACH100 series, 200series and 400 series - price just 
>over 1K for the lot). 
>
>The implication is therefore totally unfair. 


Hi David,
Nice to see you around here.

Regarding my defence of the Lattice software ;-
The original thread was about having to manually partition a design. That is true but
only with the $100 starter kit. I only wished to point out that the 'real' fitter is 
a different kettle of fish altogether.

As for the AMD devices, well that is just my opinion. However good the MINC fitter is
(and it is), the MACH architecture does not lend itself to ease of use where a re-fit
with fixed pins is concerned.

I apologise for the 2K Pounds, my scrambled brain swapped the numbers around.

Cheers,
Trevor








Article: 221
Subject: Re: Xilinx 4000
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 27 Sep 1994 07:58:00 GMT
Links: << >>  << T >>  << A >>
In article marting@hpqtdla.sqf.hp.com (Martin Curran-Gray) writes:

>After several years of 3000 Series Xilinx work, I'm considering a 4000
>device because of it's internal RAM.
>
>I was wondering if anyone with experience of the 4000 RAM could give
>some hints, or just some general 4000 best practices??
>
>If people prefer to mail direct rather than post to the newsgroup,
>I'll post a summary of what I receive.
>

I have done a few XC4000 designs, and have used the RAMS.

The biggest challenge with the RAMS is reliably meeting the set-up
and hold times for the address with respect to the WE signal. This
can be difficult at high speed, because Xilinx only specifies
worstcase timing for all delays, and you can get bit by best case
times. This is not a Xilinx unique problem. The reason they dont spec
best case, is because they reserve the right to ship better silicon
to you in the future. 

There are several good articles in the 1994 data book that explain
all the issues, and give several reliable ways of using the rams.
Pages 8-127 thru 8-147.

Elsewhere on this thread, Bob Elkind has written some good stuff
that I mostly agree with. 

Bob recomends staying below 75% gate usage, and for the larger parts
I agree (4010 and up). I have (as has he) done designs in the 95%
and up usage level, and the effort is certainly non-linear. For
random logic, there is not much you can do to help the process, but
with designs that are predominantly data path, floorplanning the
design can change a difficult design into one that routes every
time. This is most notable when there are lots of BUFTs in the
design, as well as RAMS. 

Structured designs (usually data path, and vice-versa) work best if
the structured elements are placed in columns. Data flows left-right
on the BUFT lines, and control signals are broadcast up the columns.
Control signals include: CK, CE, WE, T, A4..A0, Add/Sub . The new
RPM capability makes floorplanning easier than in previous versions
of the Xilinx software.

Like the 3K products, statemachines usually are more efficient and
faster if implemented as 1-Hot.

Bob highlights in his mail that there are issues as to which Clock
buffers you use. I personally use the BUFGSs for most of my designs
because they route easier, and they only add 1 nS over the BUFGPs.
For more info on selecting which of the BUFGPs have access to which
resources, there is a fairly detailed description given by the XNFPREP
programs report: project.PRP  

Here are some excerpts of Bob's mail with my comments.

>2.  Don't use the -4 (fastest) speed grade.  Design to the -5 speed
>    grade (or slower), and then specify -4 speed grade (or whatever
>    the next fastest speed grade is) parts for production.

This seems a little over precautious / pessamistic. The Xilinx
speed files seem to be weighted to the pessamistic side already
so designs that meet timing specs acording to XDELAY have always
worked for me.

>4.  If you are clocking (reading/writing) the on-chip RAM at full speed
>    (1 write per clock cycle, with or without a read cycle in the same
>    clock cycle), you *will* need to use the system clock as the RAM
>    write pulse.  See the Xilinx RAM app notes for details.
>
>    What isn't spelled out is that there are two global clock runs which
>    are useable for the RAM WE signal.  Any of the BUFGS buffers can
>    drive either of these two runs, but each BUFGP has connectivity to
>    only one of the clock runs.  So two of the four BUFGPs (and their
>    dedicated clock pads) are useless for master clock purposes in this
>    case.  Make sure you choose your clock buffer and clock pin wisely.

Pretty much matches what I have said

>
>    I don't think the BUFGS/BUFGP delay differences are well
>    characterised; they certainly aren't described well in the data books.

The BUFGPs are about 1 nS faster than the BUFGSs.

>    You will probably be happier if you stick to the BUFGPs for all
>    clock distribution where clock skew is a concern.

The clock skew for both is < 1 nS. I have measured them both and seen
skews in the 300 to 500 pS range. Worst case skew is between an IO FF
in the middle on the top or bottom edge , and a corner IO FF

>  There are some at
>    Xilinx who would debate this contention.  I have personal reasons
>    for this conviction which relate to using the on-chip RAM.

I have seen differences in the BUFGP to BUFGS skew too, but it is
of the order of a few 100 pS, and less than 1 nS

>7.  Be careful about using both clock edges with tight timing tolerances.
>    The clock buffers have TTL thresholds and asymmetric rise/fall times
>    internally.  So 50% duty cycle clock waveforms externally don't
>    necessarily translate into 50% duty cycle square waves internally.
>    If you clock on both clock edges, you probably should provide at least
>    4 nS of timing margin.

The I/O input buffers have TTL thesholds (~ 1.5V), so a 5V square wave
of 50% duty cycle will end up being seen as more clock high time and
less clock low time, assuming equal rise and fall times. If the rise
and fall times are fast ( < 3 nS), then the effect is about 1 nS.
Slower edges will have more effect. Higher frequencies will make the
effect a higher percentage of the cycle time. Internaly the FPGAs
have their thresholds set to minimize clock stretching and shrinkage.
4nS seems like a good safe number for clock margin, when doing things
on both edges. Dont assume that CLK-BAR gets to the FFs later than CLK,
as the clock might be distributed as CLK-BAR, not CLK.

>8.  Don't be lulled by a batch of Xilinx FPGAs with excellent timing
>    margins.  All FPGA vendors, including Xilinx, are aggressively pursuing
>    smaller and smaller fab processes.  As the distribution of their
>    parts with respect to timing performance changes, and as their order
>    demand for different speed grades shift, you may get parts which
>    greatly exceed minimum timing specs.  The next month you may get parts
>    which aren't quite so fast.   So don't get over-confident from the
>    excellent yield and/or margins on the first 50 boards.

ABSOLUTELY. Thats what speed files and simulation are for: Make sure
your design will work with the slowest silicon that meets the databook
guarantees, at high temperature, and low VCC

>Any/all of these points may be pertinent to your design, or perhaps not.
>These observations may be irrelevant for succeeding generations of
>Xilinx process variations, products, etc.  In other words, your mileage
>*will* vary !

Mine varies  :-)

>
>I've designed with 4005a, 4010, and 4013; and my colleagues have designed
>with 4005h.  These are the words of wisdom which we share amongst
>ourselves.

I've designed with 4003, 4003A, 4005, 4008, 4010, and lots of XC3K

>
>I suspect that these observations apply to ASICs and FPGAs in general, and
>not just to Xilinx products, to a varying extent.  My experience is with
>Xilinx devices, however, and you can draw some conclusions from the fact
>that I've done many Xilinx designs.


All the Best
		Philip



Article: 222
Subject: Re: Xilinx 4000
From: sherlock@brtph862 (Steve Holmes NT)
Date: 27 Sep 1994 11:50:25 GMT
Links: << >>  << T >>  << A >>
Philip Freidin (fliptron@netcom.com) wrote:
: In article marting@hpqtdla.sqf.hp.com (Martin Curran-Gray) writes:

: Bob recomends staying below 75% gate usage, and for the larger parts
: I agree (4010 and up). I have (as has he) done designs in the 95%
: and up usage level, and the effort is certainly non-linear. For
: random logic, there is not much you can do to help the process, but
: with designs that are predominantly data path, floorplanning the
: design can change a difficult design into one that routes every
: time. This is most notable when there are lots of BUFTs in the
: design, as well as RAMS. 

: Structured designs (usually data path, and vice-versa) work best if
: the structured elements are placed in columns. Data flows left-right
: on the BUFT lines, and control signals are broadcast up the columns.
: Control signals include: CK, CE, WE, T, A4..A0, Add/Sub . The new
: RPM capability makes floorplanning easier than in previous versions
: of the Xilinx software.

: Like the 3K products, statemachines usually are more efficient and
: faster if implemented as 1-Hot.

I wanted to repeat this section of Philip's response, because I think
they are the most important issue.  In order to get the most out of
FPGA designs, from any vendor, it is important to figure out 
what floorplanning works best.  This gives you much better utilization
and better speed performance.  As size increase for the Xilinx parts
you tend to see the utilization go down as the routes get more difficult.
I personally feel that the best 3K part for utilization is the 3042
and the 4k part is probably the 4008 or 4010.  

Overall Philip and Martin provide some excellent rules of thumb for
FPGA designs.

Steve Holmes
sherlock@bnr.ca



Article: 223
Subject: Re: Exemplar CORE experiences?
From: bishop@utica.ge.com (David W. Bishop)
Date: Tue, 27 Sep 1994 16:57:24 GMT
Links: << >>  << T >>  << A >>
In article 4qG@ips.cs.tu-bs.de, koch@eis.cs.tu-bs.de (Andreas Koch) writes:
>We would be interested in hearing about any experiences with
>Exemplar's CORE/TopDown+ synthesis tool. It seems somewhat
>less hardware-hungry than the Synopsys suite. While our primary
>target would be Xilinx 4000 FPGAs, comments regarding other
>technologies (eg. standard-cell ASICs like ES2) would be
>useful.

We use it, and we like it.  Just remember to include the "xi4" modgen library
before you kick off the job.

Exemplar puts some hooks into the VHDL so that you can instantiate hard macros,
so if you do this you will have to make a simulation view of your device which
is different from the synthesis view.  On rare occasions we actually have to
fiddle with the .xnf files, but not often.  Sometimes we find it better to muck
with the .xnf then to use the attributes with Exemplar uses because they may
cause another tool problems.

Our current process is to synthesize VHDL with Exemplar, use Xilinx 5.0 for
place and route, then LMC models for post layout simulation.

---
                            David Bishop

INTERNET: bishop@utica.ge.com              | The opinions voiced are mine
US MAIL:  7129 E Carter Rd, Rome NY 13440  | and not my company's.
PHYSICAL: 43.150N 75.414E 650'             |



Article: 224
Subject: Re: XC1765DPD8C
From: david@fpga.demon.co.uk (David Pashley)
Date: Tue, 27 Sep 1994 20:50:56 +0000
Links: << >>  << T >>  << A >>
In article <CwqrJq.9x2@festival.ed.ac.uk> txw@festival.ed.ac.uk writes:

"Hello,
"
"I have a problem with the XC1765 serial PROM. We are using these with
"Xilinx FPGA's, and we wish to program these PROM's with an Intel Hex format
"file. Unfortunately, the programmer we have access to does not accept this
"format for these devices. We are told that we must convert the file to
"a jedec (.jed) file. So: does anyone know of a program that could fulfill
"such a function? The intel hex file is, of course, not specific to any
"particular device, whereas a .jed file is.
"
"Tomas Whitlock

I think you are being led astray by whoever told you that you need 
to use a jedec file. The jedec format is only applicable to 
programmable logic devices, whereas the XC1765 is an EEPROM device. 
Therefore (and certainly for all the leading programmer types), you 
can present the data to the programmer an any supported PROM type 
format, but definitely *not* JEDEC.

Some older programmers have trouble with this particular device as 
the susceptibility to clock pin noise is somewhat higher than the 
norm.

David Pashley
Direct Insight Ltd
The independent CPLD/FPGA experts
Tel: +44 280 700262
Fax: +44 280 700577





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