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
Olivier Hebert wrote: > > Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm > having problems configuring the device. I'm using a master serial > configuration (I'm trying to use the XChecker cable now, and a serial > PROM later). > > When I first power up the board, if I probe the CCLK pin with a scope, I > get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. > When I try to configure the device using an XChecker cable, the > frequency of the CCLK signal goes up to something like 7 MHz, even > though I'm using slow configuration. When I hit the PROG button on the > board, the frequency goes back to it's normal rate (900 kHz). Of course, > the hardware debugger says something is wrong when I try to program the > device! > > Is there something I'm doing wrong? Could the device be bad? I really > need help on this one! > You need to use SLAVE serial when using the Xchecker and MASTER serial when using a PROM. Then it should work. -- Peter CrightonArticle: 13451
I totally disagree with anyone who thinks that denser is not better. It's
like
someone asking who needs a Cray on their desk. With the advent of cores, IO
and
HDL, the future of FPGAs and programming will be one of huge resources which
can
tolerate some level of efficiency loss for the trade off of quick
development. To
the point where FPGA programming becomes more of a Software Issue, and less
of a
hardware issue. You can see the evolution already taking place. Xilinx is one
leader in that market. So is Altera, and Lucent etc.. I am glad to see the
diversity in some of the approaches and think there will be alot of growth
potential in this market. Smaller, denser devices will continue to be sought
after. Xilinx's biggest mistake (IMO) was delaying any size migration at all.
It
seems that about a year ago they were hesitating in the move downward. I
would
also look into buying Triscend if I were Xilinx. I wouldn't make it the main
focus of their business, but I think it would be a good hedge against the
other
FPGA's doing embedded cores. I think they certainly have merrit for certain
apps.
Wade D. Peterson wrote:
> Froilan P Montenegro <froilan+@andrew.cmu.edu> wrote:
>
> > What about reconfigurable computing and systems-on-a-chip with
> >programmable logic on the same die? Something like a processor core and
> >an FPGA on the same chip with some an interface for the two to
> >communicate with each other. That way if you need basic general
> >processing abilities along with some custom logic, this might allow you
> >to build a smaller, cheaper, faster implementation than current
> >processor/FPGA combinations. I'm no expert but these are two
> >possibilities I've heard.
> >
> > - Froilan
>
> I think you're right...the reconfigurable logic field is going to be
> quite exciting in the future. From what I've seen, though, it's too
> small right now to predict what's going to happen.
>
> If I really polish my crystal ball (it's a bit rusty sometimes) I can
> see entire systems made from reconfigurable logic. The hardware would
> be booted in much the same way as operating systems are now. This is
> a shear fantasy at this point, but it isn't beyond the realm of
> possibilities.
>
> Wade Peterson
> Silicore Corporation
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 13452
I don't think that Marshall was the one who made the choice.
Anonymous wrote:
> This thought should be worrying not only XILINX shareholders,
> but also, - XILINX users, who have invested a lot of efforts
> and money into mastering XILINX tools.
>
> Why should we expect XILINX shutdown in the foreseeable future?
>
> 1) XILINX has started as successful innovative company and won
> essential part of the market. But that's in the past ...
> Recent history of XILINX is a sequence of disastrous failures
> to deliver satisfactory quality at reasonable price.
> Remind heart-breaking stories with 8000, 6200, 5200 series!
> Lacking new ideas, XILINX is trying to sell their old 4000
> series wrapped into Spartan envelope. And now Virtex becomes
> too late answer on Altera designs.
>
> 2) XILINX applies tremendous efforts to reduce the price and ...
> the quality of its development tools.
> It was reported by many customers in this particular newsgroup
> that XILINX Foundation is worse than XACT, and each subsequent
> version of Foundation is worse than previous.
> Currently the quality of development tools is so bad that XILINX
> almost gave up any attempts to fix endless stream of bugs.
> The bugs are just stored until next version of Foundation :
>
> 3) XILINX support service became some sort of psychoanalyst to
> keep users calm and to avoid bodily damage (and chip damage)
> caused by desperate customers. XILINX is afraid to reveal
> an obvious thing: there is no support for ALDEC software
> that constitutes the principal part of Foundation (design flow,
> schematics and simulation).
>
> 4) And now the last news:
> MARSHALL does not sell XILINX chips any more.
> Obviously, they are feeling where the things go.
>
> Good bye XILINX ...
>
> *************
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 13453
I agree with this!!!
Peter Alfke wrote:
> Wade D. Peterson wrote:
>
> > My Christmas wish list this year includes an ANSI/IEEE standard for
> > standard FPGA arcitectures. That way all of the application and tool
> > developers could get some of their sanity back. That would also
> > really push FPGAs into the commodity realm. Imagine 5-10 vendors of
> > FPGAs all with a similar architecture!
> >
>
> Don't hold your breath. It worked for DRAMs because they really have a
> simple, narrowly defined function, ( at least until recently ). And
> their business has turned into a disaster.
> FPGAs must stay more diverse, and we need competitive innovation to
> advance the state of the art. If that leads to some confusion and even
> chaos, so be it.
>
> Just look at the battle between Altera and Xilinx. It has been the
> driving force that brought you better, bigger and faster devices at an
> incredibly fast pace.
>
> Americans like competition, and everybody wants to win.
>
> Standardization would kill innovation and turn these FPGA houses into
> drab commodity factories that compete on nothing but price.
>
> Not my idea of fun.
>
> Peter Alfke
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 13454My concern, however, would be whether these better, bigger and faster devices introduced at an incredibly fast pace are going to have the lifetime of the older devices such as the 3k and 4k family. This is quite relevant to industrial products which tend to have long lifetimes. I realise you people like to have "fun" but there is clearly a tradeoff there. Xilinx have a good record for maintaining production of "old" parts and I wonder if this will continue. >Just look at the battle between Altera and Xilinx. It has been the >driving force that brought you better, bigger and faster devices at an >incredibly fast pace. > >Americans like competition, and everybody wants to win. > >Standardization would kill innovation and turn these FPGA houses into >drab commodity factories that compete on nothing but price. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13455
In article <743q9t$sl1$1@nnrp1.dejanews.com>, shailbains007@my-dejanews.com says... > What factors would determine the *lowest* clock frequency that can drive a > given digital circuit? (I can very well understand the existence of a an > upper limit.) Chips that use PLLs to generate internal clocks have a lower frequency limit due to PLLs having lower frequency limits (unless a PLL bypass mode is provide as is sometimes the case). -- Rich Iachetta iachetta@us.ibm.com I do not speak for IBM.Article: 13456
Joseph H Allen wrote: > <snipped> > What is LVPECL and LVDS? I've heard of LVTTL, but not any of these others. > Are they ASIC I/O options or something? I think the I/O really needs to be > ECL or PECL since there are well established ECL logic families, ECL > oscillators/PLLs and ECL A/D and D/A converters. There must be some way to > make ECL-compatiable drivers and receivers with MOSFETs on CMOS FPGAs. They > did it with GaS. > LVPECL is just low voltage PECL, used for 3.3V-rated ECL devices. The signal swing is the same, just shifted relative to the reduced VCC reference. Motorola and Synergy seem to be moving in this direction for newer parts. LVDS is a Low Voltage Differential Signalling. The relevant standards are ANSI/TIA/EIA-644 and the IEEE 1596.3 LVDS-SCI. Lots of good info on LVDS can be found on National's site at http://www.national.com/appinfo/lvds/. One big plus for LVDS is that it is compatible with standard CMOS processes and so it is available from ASIC vendors like LSI Logic, etc. I think ECL type I/O is just hard to do with CMOS, probably requiring extra processing steps. A neat new part that has come out, the MAXIM 3885, is a 3.3V 2.5 GHz 1 to 16 demux that uses LVDS outputs. About half the power of the ECL/GaaS alternatives, and much cheaper, too, at <$40! It would be nice to be able to interface this directly to an FPGA without needing a bunch of quad translators. regards, Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 13457
Peter wrote: > My concern, however, would be whether these better, bigger and faster > devices introduced at an incredibly fast pace are going to have the > lifetime of the older devices such as the 3k and 4k family. This is > quite relevant to industrial products which tend to have long > lifetimes. ...Xilinx have a good record for maintaining production of > "old" parts > and I wonder if this will continue. > Thanks for giving us credit for very carefully executes obsolescence plans. The normal sequence is that older parts become less popular since they lack the features and speed of the new families, and their price doesn't move down as fast as that of the new mainstream parts. Once the market really dries up, we issue plenty of warnings and "last-time buy" messages. Even then, we have the parts available for well over a year, and then we hand it over to an "after-life" company. We are right now slowly getting out of XC4000A and XC4000H, because there really is almost no demand. If you use very old parts, make sure you inform the sales channel about your future needs. Virtex is expected to dominate the more demanding designs in the near future, but you can be sure that XC4000XL will be alive and kicking for a very, very long time. In the future, there will be less of a speed-creep, ( devices "secretly" getting faster and faster, whether the user wants it or not ). Now the process is coupled to the supply voltage, and we cannot migrate to a faster process without changing the voltage and thus the part designation. That is actually good news for people concerned about min delays. They will remain more stable. Peter Alfke, Xilinx ApplicationsArticle: 13458
d.cary@ieee.org wrote: > > I collect Big endian vs. little endian information at > http://www.rdrop.com/~cary/html/endian_faq.html > . > > I have the classic article > ON HOLY WARS AND A PLEA FOR PEACE > by Danny Cohen (1980) > there. Highly recommended. > > I'm always astonished how many unexpected problems come from endian > misunderstandings. I'm also kind of surprised at how many people say "Use > little-endian" (or "Use Big-endian"), then try to justify it with some > "reason" that applies equally well to the other format. > > Are there any *real* reasons to favor one over the other that I haven't > already listed ? > Big-endian and Little-endian ordering can make a big difference if you send bits, bytes or words serially through some type of hardware processing filter. Examples are DSP filters and network packet processors. Depending on the function, MSBs first or LSBs first will be more natural. In implementing complex arithmetic circuits, the carry propagates from the LSB to the MSB. A circuit which does math can immediately use LSBs, but must store any MSBs until the LSBs arrive. On transmission, the LSBs (which are computed first) must be stored until all the MSBs are sent. The extra registers needed to implement this storage are costly and the flow requires overly complicated sequencing. So in math circuits with lots of adders, LSB first is going to be cheaper. This is not true for all algorithms however. Division requires both complete operands before starting and generates the MSB first. Circuits such as those used for searching a binary tree can use the MSBs first. Circuits used for for finite field arithmetic circuts such as CRC generators propagate information from the MSB to the LSBs. Best wishes, BradArticle: 13459
>... but you can be sure that XC4000XL will be alive and kicking for > a very, very long time. And what about both Spartan (5V) and Spartan XL (3.3V) parts? I'm going through this silly exercise with DRAMs now. None of the manufacturers are making 5V DRAMs any more....so if you want to do a design for a PC plug in card (of which there are AT LEAST 100 MILLION of them out there, and they ONLY have 5V, as opposed to 3.3V, on the ISA and PCI bus) and not do any voltage regulation/DC-DC conversion, you are SOL, and forced to provide 3.3V on your board. THEN, to add insult to injury, they aren't making the smaller DRAMs any more. The smallest DRAM they offer now, 'for new designs', is 64Mb per chip. So, if my embedded design only needs, say 4MB of memory in an x32 configuration, I either have to use SRAM, and lots of it, and expensive, or give it 4x the memory I need (2 4Mbx16 chips), and at twice the cost... Kind of looks like a hole in the market for embedded applications... With hundreds of millions of PCs out there, I'm still miffed that most manufacturers are abandoning the 5V market....and though the PCI bus can support 3.3V, almost no PCs support it, AND who, making a PCI card, would make a 3.3V only card (for the next few years at least), when there are so many PCs out there that don't supply 3.3V? Austin Franklin darkroom@ix.netcom.comArticle: 13460
This week's EDTN Tech Notes features an article by Lattice Semiconductor on how a PCI interface can be implemented in a CPLD. The company is offering the source code for this implementation. Check the Tech Notes section of http://www.edtn.com/pld Murray Disman Editor PLD DEsign CenterArticle: 13461
Austin Franklin wrote: > And what about both Spartan (5V) and Spartan XL (3.3V) parts? Same long-time availability as XC4000XL.Hell, Spartan XL is barely born, and you're talking about senility and death ? It's still just a spunky baby! :-) > I'm going through this silly exercise with DRAMs now. None of the > manufacturers are making 5V DRAMs any more... That's what happens in a commodity market with competition driving the manufacturers to the brink of bankruptsy. It is to the buyer's advantage that his supplier be profitable.You don't want to buy essentials at garage-sale prices. Might limit your slection... By the way, I hate the heading of this thread. But then Xilinx stock hit $60 today, so I will not lose too much sleep. :-) Peter Alfke, Xilinx ApplicationsArticle: 13462
Dan, Professionally advertising to the group isn't proper net edicate. Being that you have been around these pages for so long, you should know better than to lower yourself to that level :-). GS Daniel K. Elftmann wrote in message <366358AF.81ECA389@actel.com>... >Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds >like a good FAE Challenge. > >http://www.actel.com/products/devices/SX/chall.html > >Steve wrote: > >> I'm interfacing to a Motorola MPC 860 @50Mhz. I need to provide an >> acknowledge signal in <10ns after the Clock. To do this my PLD/FPGA >> needs to have a (Clk-Q + comb delay + tristate enable) < 10ns. >> >> So far I haven't found a CPLD to do it. What small FPGA's have the best >> crack at it??? ... or prove me wrong on the CPLD issue? >> >> So far my only practical solution is an XCS05XL-4. >> >> Comments? >> >> Steve >Article: 13463
Hi, I have almost finished a JPEG core for FPGA ASIC according to the ISO specs ISO/IEC 10918-1. I'm currently planning compliance tests according to ISO/IEC 10918-2. I've noticed that the latter mentions a data set for the compliance test. Is this available on line or I must contact ISO (probably slow) ? You can answer in this newsgroup, but if you need to email me directly, see my web page. Thanks, Enzo ------------------------------------------------------------------------------- Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 1655 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 WWW : http://www.bigfoot.com/~oceanlogicArticle: 13464
gs wrote: > Dan, > Professionally advertising to the group isn't proper net edicate. I disagree. I think proper net-etiquette can accomodate a mentioning of devices made by your employer. Otherwise I would have to sign off from this group. :-(We who work for an FPGA vendor have something to contribute - and a hell of a lot to learn. But we must tread lightly, and be constructive, honest, and fair. Just my $0.02 worth. Peter Alfke >Article: 13465
Vincenzo Liguori <enzo@nospam.com> writes:
> I'm currently planning compliance tests according to ISO/IEC 10918-2.
> I've noticed that the latter mentions a data set for the compliance test.
> Is this available on line or I must contact ISO (probably slow) ?
It's not available on-line, and I'm not sure that ISO ever even released
it officially. The fact of the matter is that the draft 10918-2 dataset
is almost valueless as a test set; you can accomplish more, more easily,
by cross-testing with any well-recognized implementation. (For example,
the free IJG code.)
Let's see, where did I put that screed ... ah, here it is...
10918-2 is completely useless for testing most production codecs anyway,
because it consists of random-noise data in a meaningless four-component
colorspace with randomly chosen sampling factors. Most of the codecs
I know about include colorspace conversion and upsample/downsample logic
and will not work on this data. If you can separate out those parts of
your codec and feed it raw subsampled data then you might have some
chance of using the 10918-2 data. It's still a pretty unfriendly test
set because it's a random-noise image --- you have no chance of getting
a go/no go indication by eyeball, you have to resort to nontrivial
statistical analysis to see whether your codec works at all! (Worse,
since your codec's roundoff errors are doubtless different from anyone
else's, you can't just compare output bits...)
And on top of that, the data set consists of one example of each of the
JPEG-defined processes. IIRC, there are only about two datastreams that
a standard baseline codec has any hope of reading. So it tells you
nothing at all about the robustness of your codec WRT real-world
variations in marker layout, restart markers, etc.
I'd suggest cross-testing with existing applications as a far more
useful and practical validation procedure than 10918-2. (The IJG code
is intended in part as a freely available reference codec for such
testing.) If you want to test the accuracy of your math, measuring the
degradation of an image over multiple compression cycles with a fixed
quality setting is a pretty sensitive check.
You can try the folks at www.jpeg.org if you want a more official
answer, but my opinion is that 10918-2 is a waste of time.
regards, tom lane
organizer, Independent JPEG Group
Article: 13466> Vincenzo Liguori <enzo@nospam.com> writes: > > I'm currently planning compliance tests according to ISO/IEC 10918-2. > > I've noticed that the latter mentions a data set for the compliance test. > > Is this available on line or I must contact ISO (probably slow) ? > > It's not available on-line, and I'm not sure that ISO ever even released > it officially. The fact of the matter is that the draft 10918-2 dataset > is almost valueless as a test set; you can accomplish more, more easily, > by cross-testing with any well-recognized implementation. (For example, > the free IJG code.) Tom, thanks for your reply. I fully agree with what you are saying and I suspected that the ISO test would have been nearly useless. Problem is that when someone wants to buy the core, especially large companies (and I had quite a few inquiries), they often ask if I have run some sort of standard test. I have run my own, with the help on the excellent IJG software, but big companies like to have some sort of "official" tests done. That's why I asked. The ISO test would have only been in addition of my own. > Let's see, where did I put that screed ... ah, here it is... > > 10918-2 is completely useless for testing most production codecs anyway, > because it consists of random-noise data in a meaningless four-component > colorspace with randomly chosen sampling factors. Most of the codecs > I know about include colorspace conversion and upsample/downsample logic > and will not work on this data. If you can separate out those parts of > your codec and feed it raw subsampled data then you might have some > chance of using the 10918-2 data. I can because my core accepts MCUs as input and outputs ECSs andviceversa. The MCU is completely programmable (as are all the tables within the limits of the baseline algorithm). I did not include colour space conversion or raster to MCU converter as every single person has its own need (laser printers CMYK or RGB, video YUV, etc) with their own interface. > It's still a pretty unfriendly test > set because it's a random-noise image --- you have no chance of getting > a go/no go indication by eyeball, you have to resort to nontrivial > statistical analysis to see whether your codec works at all! (Worse, > since your codec's roundoff errors are doubtless different from anyone > else's, you can't just compare output bits...) > > And on top of that, the data set consists of one example of each of the > JPEG-defined processes. IIRC, there are only about two datastreams that > a standard baseline codec has any hope of reading. So it tells you > nothing at all about the robustness of your codec WRT real-world > variations in marker layout, restart markers, etc. > > I'd suggest cross-testing with existing applications as a far more > useful and practical validation procedure than 10918-2. (The IJG code > is intended in part as a freely available reference codec for such > testing.) If you want to test the accuracy of your math, measuring the > degradation of an image over multiple compression cycles with a fixed > quality setting is a pretty sensitive check. Among my tests I run 10^6 8x8 blocks through FDCT and IDCT, calculatingthe PSNR with each original block. The worst was better than 52dbs. > You can try the folks at www.jpeg.org if you want a more official > answer, but my opinion is that 10918-2 is a waste of time. > > regards, tom lane > organizer, Independent JPEG Group Enzo ------------------------------------------------------------------------------- Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 2100 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 WWW : http://www.bigfoot.com/~oceanlogicArticle: 13467
Peter Alfke wrote:gs wrote: dan, Professionally advertising to the group isn't proper net edicate. Being that you have been around these pages for so long, you should know better than to lower yourself to that level :-). GS ------------------------------- Daniel K. Elftmann wrote: >Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds >like a good FAE Challenge. > >http://www.actel.com/products/devices/SX/chall.html > >Steve wrote: peter alfke wrote: > I disagree. I think proper net-etiquette can accomodate a mentioning of > devices made by your employer. Otherwise I would have to sign off from > this group. :-(We who work for an FPGA vendor have something to > contribute - and a hell of a lot to learn. > But we must tread lightly, and be constructive, honest, and fair. > Just my $0.02 worth. -------------------- hmmm ... i don't think dan's post was too bad, really. nobody spoke up about the SX parts for this problem so dan mentioned those, which was appropriate. perhaps actual performance numbers would have been better, and i followed up with those, since i was interested in that parameter anyways. also, it's interesting that SX took a different approach from act 3, it has a faster clk -> q when measured from pin-to-pin, without any flip-flops in the i/o modules, which act 3 did have. on the other hand, there are posts that are flagrantly advertising, answering technical questions with, "buy my stuff," over and over and over and over ... also, i think vendors should identify themselves, which dan did, and which peter a. always does. just a thought, rkArticle: 13468
Vincenzo Liguori <enzo@nospam.com> writes: > I have run my own, with the help on the excellent IJG software, but big > companies like to have some sort of "official" tests done. True ... whether the tests prove anything is far too often irrelevant... > Among my tests I run 10^6 8x8 blocks through FDCT and IDCT, calculatingthe > PSNR with each original block. The worst was better than 52dbs. This is good, but as far as FDCT/IDCT go there actually is a recognized accuracy test, IEEE-1180. IEEE withdrew this spec a couple years ago, for reasons that were never explained in my hearing, but it's still about as good a test procedure as you're going to find for those components. Besides, if you need buzzword compliance then any spec with a number on it is worth running ;-). Now I will modestly claim to know a few things about JPEG implementation bugs and compatibility problems ... and in my experience the DCT code is not usually the source of problems. (I can only ever recall seeing one image that appeared to be made with a broken FDCT.) The real creepy-crawlies come from bogus assumptions about marker layout, inability to cope with unusual Huffman tables or sampling factors, and so forth. And these are exactly the areas that the 10918-2 test streams won't teach you much about :-( I don't know whether you intend your hardware to produce/consume a complete JPEG file directly, or whether you expect there to be a layer of software to deal with the markers. If you expect to consume real- world JPEG files then there's no substitute for trying to read a bunch of what's out there. I have accumulated a rogue's gallery of unusual JPEGs (some valid, most not) which I can send you if you're interested in doing some stress testing. It's far from official but I daresay it'll teach you more than 10918-2 would... regards, tom lane organizer, Independent JPEG GroupArticle: 13469
Hi! Indeed, I had the mode setting wrong. I did a little soldering today and added a dip switch for selecting the configuration mode. Now, it works nicely! Thanks to everyone, this was really appreciated. Bye, OH Ray Andraka wrote: > > You need to use master serial for prom, slave serial for the xchecker. One > connects all the mode bits to '1' the other is all '0'. CCLK is sourced by > the FPGA for master serial and by the xchecker for slave serial. You need > to disconnect the xchecker when programming from a PROM to avoid > contention. The configuration speed only effects the master serial's CCLK. > > Olivier Hebert wrote: > > > Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm > > having problems configuring the device. I'm using a master serial > > configuration (I'm trying to use the XChecker cable now, and a serial > > PROM later). > > > > When I first power up the board, if I probe the CCLK pin with a scope, I > > get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak. > > When I try to configure the device using an XChecker cable, the > > frequency of the CCLK signal goes up to something like 7 MHz, even > > though I'm using slow configuration. When I hit the PROG button on the > > board, the frequency goes back to it's normal rate (900 kHz). Of course, > > the hardware debugger says something is wrong when I try to program the > > device!Article: 13470
Hi, I am currently working on a FPGA application and I choosed a chip provided in a PQFD304 package. Since my PCB tool does not provide the layout for this package, I have to draw it. So I am looking for detailed informations about this package. Where can I find them on the Web? Thanks. Riad BourguibaArticle: 13471
In article <741o75$ns$1@brokaw.wa.com>, Ken Coffman <kcoffman@intermec.com> writes >The last time I looked at FPGA Express it was not very good. I got faster >and better out of the box performance from Synplicity, but Exemplar is >better if you like tinkering under the hood. You can't go wrong with either >product. Exemplar got out first with their ASIC support, but its coming soon >from Synplicity. > I hear Synopsys already has some ASIC support ;-) But seriously, I would say that comparing these tools as a standalone FPGA synthesis solution, your results will vary considerably according to the particular benchmark. In September, Brian Dipert of EDN did an excellent, thoughtful "Synthesis shoot out" benchmarking exercise (see www.ednmag.com). FPGA Express fared well, but both Exemplar and Synplicity declined to participate. If your requirements encompass productivity issues, then remember that FPGA Express 3 is available fully integrated within the Viewlogic 7.5 toolset. So you can freely combine HDL, schematics and state diagrams, have a single flow (including integrated place and route) for all FPGAs, and use a single environment for VHDL/Verilog, post-implementation and board-level verification. David [a Viewlogic reseller, so naturally a little biased :-) ] -- David Pashley < --------------------------- < < < --- mailto:david@edasource.com | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | http://www.edasource.com < < < Fax: +44 1280 700577 | ------------------------------ < ---------------------------------Article: 13472
In article <748ek2$n4e$1@oceanite.cybercable.fr>, Riad <ardoise@cybercable.fr> writes >Hi, > >I am currently working on a FPGA application and I choosed a chip provided >in a PQFD304 package. Since my PCB tool does not provide the layout for this >package, I have to draw it. So I am looking for detailed informations about >this package. Where can I find them on the Web? > Watch out, there are at least 4 different variants of the package you describe. See http://www.emulation.com/catalog/footprints/pqfp/172-304/304.gif You should refer to the FPGA vendor's databook, and then you'll be sure to get it right. David -- David Pashley < --------------------------- < < < --- mailto:david@edasource.com | Direct Insight Ltd < < < < > Tel: +44 1280 700262 | | http://www.edasource.com < < < Fax: +44 1280 700577 | ------------------------------ < ---------------------------------Article: 13473
Go to the chip vendor's web page, and look at the package section of his data book. Use the vendor's info, otherwise subtle differences from one vendor's package to another's may screw you. Riad wrote: > Hi, > > I am currently working on a FPGA application and I choosed a chip provided > in a PQFD304 package. Since my PCB tool does not provide the layout for this > package, I have to draw it. So I am looking for detailed informations about > this package. Where can I find them on the Web? > > Thanks. > > Riad Bourguiba -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13474
See what's new on The Programmable Logic Jump Station at
http://www.optimagic.com/
The Programmable Logic Jump Station is a comprehensive set of
links to nearly all matters related to programmable logic.
Featuring:
---------
--- Frequently-Asked Questions (FAQ) ---
Programmable Logic FAQ - http://www.optimagic.com/faq.html
A great resource for designers new to programmable logic.
--- FPGAs, CPLDs, FPICs, etc. ---
Recent Developments - http://www.optimagic.com
Find out the latest news about programmable logic.
Device Vendors - http://www.optimagic.com/companies.html
FPGA, CPLD, SPLD, and FPIC manufacturers.
Device Summary - http://www.optimagic.com/summary.html
Who makes what and where to find out more.
Market Statistics - http://www.optimagic.com/market.html
Total high-density programmable logic sales and market share.
--- Development Software ---
Free and Low-Cost Software - http://www.optimagic.com/lowcost.html
Free, downloadable demos and evaluation versions from all the major
suppliers.
Design Software - http://www.optimagic.com/software.html
Find the right tool for building your programmable logic design.
Synthesis Tutorials - http://www.optimagic.com/tutorials.html
How to use VHDL or Verilog.
--- Related Topics ---
FPGA Boards - http://www.optimagic.com/boards.html
See the latest FPGA boards and reconfigurable computers.
Design Consultants - http://www.optimagic.com/consultants.html
Find a programmable logic expert in your area of the world.
Research Groups - http://www.optimagic.com/research.html
The latest developments from universities, industry, and
government R&D facilities covering FPGA and CPLD devices,
applications, and reconfigurable computing.
News Groups - http://www.optimagic.com/newsgroups.html
Information on useful newsgroups.
Related Conferences - http://www.optimagic.com/conferences.html
Conferences and seminars on programmable logic.
Information Search - http://www.optimagic.com/search.html
Pre-built queries for popular search engines plus other
information resources.
The Programmable Logic Bookstore - http://www.optimagic.com/books.html
Books on programmable logic, VHDL, and Verilog. Most can be
ordered on-line, in association with Amazon.com
. . . and much, much more.
Bookmark it today!
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