Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 201Jim 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 MartinArticle: 202
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-7206Article: 203
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.comArticle: 204
** 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: 205SRC 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.orgArticle: 206
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.orgArticle: 207
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 UnitArticle: 208
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 UnitArticle: 209
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.comArticle: 210
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
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 ViredayArticle: 212
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 700262Article: 213
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 700262Article: 214
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.comArticle: 215
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: 216We 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 26Article: 217
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.ukArticle: 218
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
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: 220david@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, TrevorArticle: 221
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 PhilipArticle: 222
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.caArticle: 223
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: 224In 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:
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