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
In article <5mjqq1$m3j$1@news01.btx.dtag.de>, HTD <Hans Dermot Doran> wrote: >On Mon, 26 May 1997 20:47:42 GMT, stuart.summerville@practel.com.au >(Stuart Summerville) wrote: > >>Hi all, >> >>I have a 208pin PQFP fpga (0.5mm pitch) on a board. I am having >>problems with pin connections to the board. Attempting to re-heat the >>solder to make a clean connection seems to create problems with >>surrounding pins - it doesn't take much to get a minute solder bridge >>between two pins. >> >>Two questions: >> >>1) Do any of you find such packages tend to come in with such >>connection problems? >> >>2) What is the feeling about attempting to re-solder such pins if a >>connection seems to be flakey? Am I wasting my time trying to fix it? >>Maybe if some pins have flakey connections then others on the same >>chip are likely to (eg. if some are bent down too much, then obviously >>the others are at a different level...). >> > Resoldering can be done, but I am no good at it. Sometimes the chip has to be removed and the board traces will only handle 3-4 removals before the traces separate from the board. The easiest solution for me was to go with the Altera 208PQFP socket since I'm using an OTP FPGA. Good luck. -steenlArticle: 6551
You can pick up a pretty good interactive tutorial (works with your
web browser) at :
http://rassp.scra.org/
This CD ROM is great. You have nice, pleasant graphics and you are
always a click away from the VHDL Language Reference Manual. It is
well structured and is easy to follow. It was developed by IEEE
and RASSP (Rapid Prototyping of Appl. Specific Signal Processors).
Cheers,
Sam Falaki
Article: 6552On Mon, 02 Jun 1997 14:04:15 +0100, Iakovos Stamoulis <I.Stamoulis@Sussex.ac.uk> wrote: >Sorry... but what exactly makes Altera FLEX non-PCI compliant ??? >From reading the relevant application note, it look-like altera are >more than capable to provide the driving characteristics and speed >to be PCI Compliant. >From reading this posting, it looks like Altera documentation has been misread by another NG member. Read the documentation fully. I did. So I would suspect have most others following the thread where we started and finished this one. Altera FLEX10K is not PCI compliant. Every device they have shipped is not compliant. Every part sitting with their disti network is not compliant. Every piece coming off the line is not compliant. End of story. Dead, buried, WORM FOOD. Stuart A Lucent distributor speaking for himself.Article: 6553
Gaaah!!! On 2 Jun 1997 18:29:32 GMT, evjapps@inet.uni-c.dk wrote: >Jac is right about Altera's compliance to the PCI spec's. Please look at the datasheets for their new PCI master/target MegaCore function with DMA. >This function allows zero wait state Read & write at 33 MHz operation. It uses approx. 50% of an EPF10K30-3 and is easily modified to what ever parameters is neaded. Parrot! Please remove Altera's hand from your bottom. You work for an Altera distributor do you not? Are you an Altera FAE for them perhaps? I didn't just look at the specs. I printed them, read them, double checked them with the PCI spec and made my conclusions: Altera FLEX10K is not PCI compliant. Doesn't matter how much marketing spin you put on it, or how many glossy adverts you throw at the market, or how much html you use on your web site. 1 The Clock pin capacitance breaks the spec. This is due to be changed, so they will be compliant on this checkbox at some point in the future. 2 The pci_a core as it stands has some signals from the PCI bus driving two pins on the FLEX10K device. That breaks the spec, and puts a maximum 20 pF load on the pin. Today, they are not compliant with the PCI specification, end of story Stuart A Lucent Distributor speaking for himself.Article: 6554
In article <c67vxp2xq.fsf@ite127.inf.tu-dresden.de>,
Achim Gratz <gratz@ite.inf.tu-dresden.de> wrote:
>
> I'm all for it.
>
Excellent!
>
> This should be reflected by a change to the c.a.fpga charter also.
>
This is an interesting idea; I hadn't thought of trying to change
the original c.a.fpga charter, but that is a possibility if c.a.rpu
is created.
>
> I hope that RPU is not already used for some specific product. If it
> is, c.a.reconfig or some such seems more appropriate.
>
I understand that c.a.reconfig was debated as a choice of name for
c.a.fpga; however, the term ``reconfig'' is also used frequently in
fault-tolerant computing, which could attract a different audience (much
as the term ``FPGA'' has attracted a particular audience to
comp.arch.fpga)
Anyone else have suggestions for a better name?
--Mike A
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 6555
> Two wrongs don't make a right. I think it would be better to spin off a
> real engineering-oriented fpga group (sci.engr.electrical.fpga?) and
> then make a serious effort to move the posts not in keeping with the
> original comp.arch.fpga posts off c.a.fpga to s.e.e.fpga. Many uses of
> FPGAs have nothing to do with computing, and
> should not be discussed under the comp.arch hierarchy, e.g., FPGAs used
> in comms
> equipment and having little or no connection with any CPU
Based on the charter of c.a.fpga, it's clear that a lot of the current
discussion was intended to take place somewhere besides the
``reconfigurable computing'' newsgroup (see the charter); i think everyone
agrees on this (including the person who did the original charter).
The question seems to be how best to proceed, given this.
Creating a ``sci.engr.electrical.fpga'' for FPGA discussions and
keeping c.a.fpga for reconfigurable computing is one
alternative, what I meant by the `reclaim'' approach.
Reconfigurable computing folks would then politely steer FPGA
discussions to the new s.e.e.fpga group.
I have a feeling, however, that as long as the reconfigurable
computing newsgroup contains the term ``fpga'', this will happen
a lot -- not that this would be bad, just that it will occur
relatively frequently. (I could be completely wrong ;-)
On the other hand, if the reconfig newsgroup does NOT contain
the term ``fpga'', some reconfig computing folks may not
realize it exists... until someone from c.a.fpga steers
them to it.
Do people agree that there's a difference between reconfigurable
computing and FPGAs? Do these topics warrent separate discussion
spaces? (Comments?)
I think they do, and it's really a matter of deciding on
the best places (i.e., two newsgroup names) in which to discuss
the two topics. (Not to say *that* will be an easy task ;-)
>
> Since this raises issues of how to keep newsgroups on-charter, and what
> to do about newsgroups that have generally accepted discussion domains
> at variance with their charters, I am crossposting to news.groups.
> Perhaps the news.groupies there can add further insight.
Good idea, it'll be interesting to see these responses
--Mike A
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 6556
Reiner,
Yes, a reconfigurable computing newsgroup would attract people with a
variety of backgrounds and promote new ideas. (No doubt, the
parallel-processing community would take part.) In this context,
reconfigurable computing goes beyond the current technology (i.e., fpgas)
and is viewed as a new paradigm, ``computing through structural
programming'' as you put it. ^^^^^^^^^^
Is comp.arch.fpga the right forum to discuss such topics? It's
charter indicates that it *should* be, but the current discussions
on FPGA CAD tools seem to indicate otherwise. Again, it seems
to be a quesiton of how to proceed: ``reclaim'' comp.arch.fpga for
reconfigurable computing and move fpga discussions to another
(new) newsgroup; or leave comp.arch.fpga in place (with a modified
charter was one suggestion...) and create a new reconfigurable-computing
newsgroup, such as comp.arch.rpu
--Mike A
> I appreciate your efforts. I would propose, that you establish this
> group.
>
> On the long run it will address also people from scenes other than
> comp.arch.fpga. Parallel processing conferences are in a process of
> reorientation their scope, where also reconfigurable is added as an
> alternative to instruction level parallelism. An example is IPPS'98
> (International Parallel Processing Symposium, Orlando, Florida, End of
> March 1998)
>
> Funding agencies started shifting funds from parallel to reconfigurable
> (e. g. see the DARPA adaptive computing systems program). This indicates
> the kind of a part of the clientele to be reached by the proposed
> newsgroup. I could support you in announcing the group via our e-mailing
> lists including such people.
>
> This new group would stress "computing thru structural programming"
> rather than tinker toy approaches to hardware implementation.
>
> Please, do not hesitate.
> Best regards
> Reiner Hartenstein http://xputers.informatik.uni-kl.de
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 6557Hello from Santa Monica (California) to the End of the world.... Dear David Thank you for your reply. > I have used XC4000 JTAG: it works well. I used a setup whereby the Did you do the "programming" with a third unit, like an uController or PAL? Were you able to do all the WR and other signals needed to programm through the JTAG only? (wow if so) > BTW who makes those Flash parts you mention, the ones with a JTAG Actually no one. I hoped, that somebody nows one, but many asked only. But it would be a good thing, hm? Can you think of an approach to do it with the Xchecker instead of the JTAG? I have not yet read myself into JTAG, do you now where to look? Thank you your Jimmy D.Article: 6558
Hi Folks,
The preliminary discussion about comp.arch.rpu is generating good ideas:
I got the following suggestion off-line; any comments? (my comments
appended at end)
>
> When I look at:
> comp.arch.rpu
> it really has no meaning at all. (I'm not trying to be rude, but unless
> one already know what "RPU" means, one has no clue what this group would
> be for.)
>
> A name like:
> comp.arch.fpga.reconfigurable
> comp.arch.fpga.reconfig
> tells people what the group is for. It is in the fpga hierarchy since
> it deals with reconfigurable computing using FPGAs. Or maybe:
> comp.arch.fpga.computing
> but I think this is less clear.
>
> If you want to do the fpga world a big service, how about proposing
> that comp.arch.fpga be reorganized into:
> comp.arch.fpga Miscellaneous
> comp.arch.fpga.tools CAD Tools
> comp.arch.fpga.devices Device info (chips, proms, programming, etc.)
> comp.arch.fpga.designs Designs using FPGAs (system and single chip)
> comp.arch.fpga.reconfigurable Reconfigurable computing
>
> That way people can find exactly the information they need and not be
> bothered with extraneous data. (For example, I would not read the
> tools groups, but would read the rest.)
>
> So if you think this is a good idea, you really ought to propose a
> reorganization now. That way it fixes the problem forever, instead
> of having to educate people down the road about separating out the
> topics...
>
I like the idea of a hierarchical reorg a lot. Comp.arch.fpga currently
serves a valuable purpose, which I for one would like to see left
undisturbed as much as possible. The suggestion to reorg hierarchically
would largely accomplish this; exactly which sub-groups to use would be
another matter, but in principle I like the approach.
On the other hand, several folks have suggested that much of what is
curently discussed in comp.arch.fpga does not belong under the comp.arch
hierarchy, but rather under the Science/Engineering/Electrical hierarchy;
for example, creating ``sci.engr.electrical.fpga'' for this purpose.
The logical reasoning behind this approach is clear; however, my feeling
is that it would fragment discussion on fpgas (by splitting discussions
across hierarchies), whereas the hierarchical reorg approach would have
a more orgainzing effect on the expanding fields that involve fpgas.
Any comments?
--Mike A
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 6559alexander@eecs.wsu.edu wrote: > > Hi Folks, > > The preliminary discussion about comp.arch.rpu is generating good ideas: > I got the following suggestion off-line; any comments? (my comments > appended at end) > > > > > When I look at: > > comp.arch.rpu > > it really has no meaning at all. (I'm not trying to be rude, but unless > > one already know what "RPU" means, one has no clue what this group would > > be for.) > > > > A name like: > > comp.arch.fpga.reconfigurable > > comp.arch.fpga.reconfig > > tells people what the group is for. It is in the fpga hierarchy since > > it deals with reconfigurable computing using FPGAs. Or maybe: > > comp.arch.fpga.computing > > but I think this is less clear. > > > > If you want to do the fpga world a big service, how about proposing > > that comp.arch.fpga be reorganized into: > > comp.arch.fpga Miscellaneous > > comp.arch.fpga.tools CAD Tools > > comp.arch.fpga.devices Device info (chips, proms, programming, etc.) > > comp.arch.fpga.designs Designs using FPGAs (system and single chip) > > comp.arch.fpga.reconfigurable Reconfigurable computing > > > > That way people can find exactly the information they need and not be > > bothered with extraneous data. (For example, I would not read the > > tools groups, but would read the rest.) > > > > So if you think this is a good idea, you really ought to propose a > > reorganization now. That way it fixes the problem forever, instead > > of having to educate people down the road about separating out the > > topics... > > > > I like the idea of a hierarchical reorg a lot. Comp.arch.fpga currently > serves a valuable purpose, which I for one would like to see left > undisturbed as much as possible. The suggestion to reorg hierarchically > would largely accomplish this; exactly which sub-groups to use would be > another matter, but in principle I like the approach. > > On the other hand, several folks have suggested that much of what is > curently discussed in comp.arch.fpga does not belong under the comp.arch > hierarchy, but rather under the Science/Engineering/Electrical hierarchy; > for example, creating ``sci.engr.electrical.fpga'' for this purpose. > The logical reasoning behind this approach is clear; however, my feeling > is that it would fragment discussion on fpgas (by splitting discussions > across hierarchies), whereas the hierarchical reorg approach would have > a more orgainzing effect on the expanding fields that involve fpgas. > > Any comments? > > --Mike A > > -------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet I left all the above because it deserves a reading and rereading. RPU stands for reconfigurable processing unit. You may not know it now but you will in the near furture. It is a reconfigurable hardware unit with a micro processor or processor port and it is open. Nobody owns the trademark on RPU. For example I would not call the Colt chip a FPGA but I would call it an RPU. The restructure thing is like saying we should have comp.arch.transistor.cpu because the first cpus used (and continue to use) transistors. If you look the only thread going about reconfigurable computing here is this one. When we just had a reflector there where not that many posts but all of them where about reconfigurable computing. I say axe comp.arch.fpga and put it where it belongs then create comp.arch.rpu -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 6560
In article <865302993.27430@dejanews.com>, alexander@eecs.wsu.edu says... > >Hi Folks, > >The preliminary discussion about comp.arch.rpu is generating good ideas: >I got the following suggestion off-line; any comments? (my comments >> A name like: >> comp.arch.fpga.reconfigurable >> comp.arch.fpga.reconfig >> tells people what the group is for. It is in the fpga hierarchy since >> it deals with reconfigurable computing using FPGAs. Or maybe: >> comp.arch.fpga.computing >> but I think this is less clear. >> >> If you want to do the fpga world a big service, how about proposing >> that comp.arch.fpga be reorganized into: >> comp.arch.fpga Miscellaneous >> comp.arch.fpga.tools CAD Tools >> comp.arch.fpga.devices Device info (chips, proms, programming, etc.) >> comp.arch.fpga.designs Designs using FPGAs (system and single chip) >> comp.arch.fpga.reconfigurable Reconfigurable computing >> > A few weeks ago I posted asking about a more relevant newsgroup for reconfigurable computing... I searched all the available group names and came up with a few short possibilities, c.a.fpga and perhaps those concerning vhdl....Of course neither contain direct (or little) RC discussion. It is certainly true that .rpu would not have made it to my short list, whereas reconfig or fpga or reconfigurable etc would. I would strongly support including fpga and the root reconfig in the new name. I also strongly agree that the name should not be tied to any available platform. I do look forward to discussions in this group. As the adoption of the technology grows and begins to dramatically change digital hardware :), this will probably become a very active newsgroup, so planning now would be very wise. I vote for the c.a.fpga.various groups listed above... Foresight now will make us all happy later. Bruce Pirger includingArticle: 6561
Kate Meilicke <kate.meilicke@xilinx.com> wrote in article <339318E6.F2F@xilinx.com>... > Bill, > > Any new designs should use edif or sedif. XNF is still supported for > legacy designs and some EDA tools don't currently support EDIF. > > Kate It would be very helpful for those of us with homegrown tools, who are considering a move from XNF to EDIF, if Xilinx would publish a specification of how to emit EDIF for Xilinx tools, e.g. how to target specific device features, specify timespecs, placement constraints, etc. That is, don't repeat the XNF experience where the information was available only under NDA or through "reverse engineering" of otherwise-generated XNF. Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't yet received an update since 6.0 and it doesn't appear to be on the Xilinx website. Thank you. Jan GrayArticle: 6562
A contrarian perspective. I favour the status quo. The volume on the present group is quite manageable. I imagine many are like me -- interested in both reconfigurable computers *and* general FPGA information -- and it is just plain convenient to have all the traffic dumped into one happy milieu. Splitting the group into two will not magically create CONTENT or VOLUME in the comp.arch.fpga.really.reconfig.really branch. Although there is not much discussion about reconfigurable FPGA based computers, the other FPGA traffic in this group is not at fault. Many times I have seen groups split, only to have half of the messages cross-posted to both groups, and worse. Not to mention the hassles of pestering one's news admin to be sure to carry the new group, etc. No, it seems better to wait until there is some sustained custom/reconfig computing discussion traffic first. However, I am quite sold on a comp.arch.fpga.split.discussion newsgroup! Jan GrayArticle: 6563
>It would be very helpful for those of us with homegrown tools, who are >considering a move from XNF to EDIF, if Xilinx would publish a >specification of how to emit EDIF for Xilinx tools, e.g. how to target >specific device features, specify timespecs, placement constraints, etc. >That is, don't repeat the XNF experience where the information was >available only under NDA or through "reverse engineering" of >otherwise-generated XNF. >Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't >yet received an update since 6.0 and it doesn't appear to be on the Xilinx >website. You probably won't. Xilinx has historicly considered this information to be propietary.Article: 6564
On Fri, 30 May 1997 18:09:09 GMT, alexande@eecs.wsu.edu (Michael Alexander - EECS) wrote: >Reconfigurable Computing Enthusiasts, > >I would like to solicit preliminary input on the following (draft) proposal >for creating a newsgroup devoted to reconfigurable computing. Yes! This theme needs its own place! Robert M. Muench SCRAP EDV-Anlagen GmbH, Karlsruhe, Germany ==> Private mail : r.m.muench@ieee.nospam.org <== --> remove .nospam from my e-mail address <-- ==> ask for PGP public-key <==Article: 6565
alexander@eecs.wsu.edu writes:
> I like the idea of a hierarchical reorg a lot. Comp.arch.fpga currently
> serves a valuable purpose, which I for one would like to see left
> undisturbed as much as possible. The suggestion to reorg hierarchically
> would largely accomplish this; exactly which sub-groups to use would be
> another matter, but in principle I like the approach.
You should know what tends to happen to such reorgs. At the very
minimum, that would require to remove comp.arch.fpga (the top group of
an hierarchy should never be active).
You are proposing a group for the discussion of Reconfigurable
Processing Units. While FPGA are certainly the current way to
experiment with them in hardware, they have not much else to do with
FPGA. That would make this group inappropriate as a subgroup to
c.a.fpga as it narrows the topic unnecessarily, IMHO. It is certainly
an architectural topic, so comp.arch is the "right" hierarchy to put
it in. Reconfig computing might even be split in the future if it
ever becomes mainstream.
This leaves the question what to do with c.a.fpga, since the stuff
that's most frequently discussed here has little relevance to computer
architecture. My suggestion is to change the charter at least, if not
moving it to sci.engineering.fpga altogether. If we want to be able
to complain about inappropriate posts in UseNet, the least thing we
should do is get the charters and hierarchy right.
So the cleanest way would be to _rename_ comp.arch.fpga so that
there's no doubt that we want to talk about reconfigurable computing
here (if the voters agree). At the same time c.a.fpga becomes
defunct, sci.eng.fpga pops up. Whether s.e.fpga is a hierarchy in
itself from the start needs to be decided, I don't think the current
volume warrants it.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 6566note: last paragraph of this post is the most important; feel free to skip right down there alexander@eecs.wsu.edu wrote in article <865288300.15181@dejanews.com>... <snip> [some discussions about steering posts and other stuff] >Do people agree that there's a difference between reconfigurable >computing and FPGAs? Do these topics warrent separate discussion >spaces? (Comments?) nope; i've seen some discussions of reconfigurable stuff in this newsgroup, which makes sense, since it's an application of fpgas. however, the volume of *all* of the discussions about fpga's combined are relatively low and easily fit into one newsgroup. reading two newsgroups and seeing lots of posts and 'steers' perhaps would be more annoying than simply reading one newsgroup with both reconfigurable and non-reconfigurable posts in it and making a decision on what to read and what not to read. then again, it's probably not the biggest thing in life in general. but would hate to have the net police saying, "you should post there, not here" in their pompous tone which is usually the result of being a religious zealot to the net and some rules somewhere which few ever even know exist. and i may, perhaps, start to sweat if the discussion about an fpga-type perhaps needs to go into it's applicability to reconfigurable computing in concert with other features; but then i must decide where to post so the net zealots don't come after me (and i'm not paranoid, they've come after me before for discussing how to write i/o commands for win 'nt and 95 in delphi - oh, the shame of it all - they droned on and on and on in their religious fervor, quoting all these rules and netiquette and other nonsense), and i will nervously make my selection, and quiver when i press the post to group button. of course, i gotta start worrying about which topics are worthy of cross-posting; and if i cross-post in the middle of a thread, gotta include enough background so somebody can pick up the topic and understand it. see, it's already too much for this minor league brain of mine. <someone said> >As you may know, the original charter for Comp.arch.fpga intended >this newsgroup as a discussion place for reconfigurable computing. >(See ftp://ftp.uu.net/usenet/news.announce.newgroups/comp/comp.arch.fpga) >At that time, Comp.arch.fpga was deemed the most appropriate name >for such a newsgroup. >At this time, I think it's worthwhile to consider creating a new newsgroup >devoted to reconfigurable computing, leaving Comp.arch.fpga to serve in >its current (very useful) role. If you're intersted in reconfigurable >computing, please read the draft proposal below. so, if this place is intended for reconfigurable computing, and it is definitely not overloaded, it seems that we're in pretty good shape. <someone else said> >is comp.arch.fpga the right forum to discuss such topics? It's >charter indicates that it *should* be, but the current discussions >on FPGA CAD tools seem to indicate otherwise. uh, perhaps the net police should come out and send this cad tool discussions to where-ever cad tool discussions should go. but then again, i was just reading about atmel's new cad tools to enable reconfigurable computing on their at6000 series. rats, more worries about cross-posting. <yet someone else said> > CHARTER > The proposed unmoderated newsgroup Comp.arch.rpu will be open > to discussions on topics related to reconfigurable computing, > which can be described as the practice of using in-system-reconfigurable > processing units (RPU) to accelerate operations in general-purpose computing. now, what if i wish to discuss reconfigurable 'puting in NON-general-purpuse computing. where do i post that? <and that yet someone else also said> > RATIONALE > Reconfigurable computing is an emerging field that represents a significant > departure from traditional computing models (e.g., von Neuman). Although > many of these systems use FPGAs, reconfigurable computing systems represent > an important new computing paradigm, making such discussions less and less > appropriate for Comp.arch.fpga, which is largely focused on CAD tools and > issues pertinant to traditional static FPGA designs (e.g., ASICs, glue logic). by the way, we have done and seen some designs in fpga's that are anything but static - quite programmable on the fly (like 160 personality changes per second), for example, and others that showed a great deal of reprogrammability - although without the ultimate potential of some of the newer systems. of course, the sram fpga proponents (and guys marching around with reconfigurable computing buzzwords flowing from their mouths who've never even designed an fpga) were less than thrilled when they found out what people are doing with the evil antifuse-based devices. like actually thinking about what they're doing. ---------------------------------------------------- so, the big conclusion is: the volume of posts to this newsgroup is moderate and well-sized now, and i don't see a big overflow of posts on reconfigurable computing making this newsgroup unreadable or confusing. rk _____________________________ p.s. what do the field programmable interconnect guys have to say? do they have their own newsgroup? p.s.s. how about the field programmable analog circuits? maybe we should be building some more analog computers? maybe they'll be coming back in style like other recycled ideas. p.s.s.s. i saw in the paper an ad for a board with the xilinx xc6216 on it that plugs into the pci bus; i called the number in the ad and nothing has happenned. called back, same deal. so, anybody know where i can buy one of these boards? want to get it quick, too, for an e-valuation. <-- this part of the post is serious.Article: 6567
In article <01bc6fe8$794e6d50$30a5b8cd@p5-166>
jsgray@acm.org.nospam "Jan Gray" writes:
> It would be very helpful for those of us with homegrown tools, who are
> considering a move from XNF to EDIF, if Xilinx would publish a
> specification of how to emit EDIF for Xilinx tools, e.g. how to target
> specific device features, specify timespecs, placement constraints, etc.
> That is, don't repeat the XNF experience where the information was
> available only under NDA or through "reverse engineering" of
> otherwise-generated XNF.
Absolutely right. If Xilinx want to reduce their support costs they
could publish their EDIF syntax in YACC format and even produce a
stand-alone syntax checker.
Simon
Article: 6568testArticle: 6569
There is comprehensive information on all matters related to programmable
logic
on the Programmable Logic Jump Station at 'http://www.optimagic.com'. It
has information on:
FPGA/CPLD Companies: http://www.optimagic.com/companies.html
Design Software: http://www.optimagic.com/software.html
Consultants: http://www.optimagic.com/consultants.html
Books: http://www.optimagic.com/books.html
Boards: http://www.optimagic.com/boards.html
Newsgroups: http://www.optimagic.com/newsgroups.html
FPGA/CPLD Research: http://www.optimagic.com/research.html
Information Search: http://www.optimagic.com/search.html
--
Steven Knapp
OptiMagic(tm) Logic Design Solutions
E-mail: sknapp @ optimagic.com
Programmable Logic Jump Station: http://www.netcom.com/~optmagic
Henry F Fernandes <hff135@skorpio3.usask.ca> wrote in article
<5mkjk8$52@tribune.usask.ca>...
| I am new to this area. Can any point out a FAQ or any suitable site on
the
| web where someone like me can find information?
|
| --
| ----------- Henry Fernandes (hff135@cs.usask.ca)
| http://www.cs.usask.ca/homepages/grads/hff135/index.html
| - Glory Glory Man United
|
Article: 6570[snip] | >Perhaps such a EDIF-for-Xiilnx specification is available, but I haven't | >yet received an update since 6.0 and it doesn't appear to be on the Xilinx | >website. | | You probably won't. Xilinx has historicly considered this information | to be propietary. | The XNF specification was previously available under non-disclosure to practically any user with a valid reason to want it. However, you can now obtain a copy of the Xilinx .XNF specification via their website at 'ftp://ftp.xilinx.com/pub/documentation/xactstep6/xnfspec.pdf', 390 KB. I haven't seen an equivalent document for Xilinx EDIF, yet. If you are interested in the M1 release, take a look at 'http://www.xilinx.com/support/techsup/ftp/htm_index/docs_M1.htm' for a list of relevant documents in Adobe Acrobat (PDF) format. -- Steven Knapp OptiMagic(tm) Logic Design Solutions E-mail: sknapp @ optimagic.com Programmable Logic Jump Station: http://www.optimagic.comArticle: 6571
| most applications heavily using arithmetics are not well supported by | the fine granularity FP circuits available commercially to-day. That's | why the research trend goes toward coarse granularity, such as e. g. | with the Kress Array (a reconfigurable array of reconfigurable ALUs - | for configuration using an optimizer: much faster and more efficient | than routing and placement - see: http://xputers.informatik.uni-kl.de). While I agree that FPGA arithmetic could always be faster, there are some truly remarkable designs using FPGAs for arithmetic processing, today. Most noteworthy are those in Digital Signal Processing. The FPGA's fast carry logic and on-chip memory make them ideal for such applications. For some standard DSP functions like FIR filters, an FPGA outperforms a leading-edge DSP processor by 10x or more! I've seen cases where a single large FPGA replaced a board-full of DSP processors. FPGAs are currently best used in fixed-point DSP applications. For those interested, here are a few relevant links: General overview of using FPGAs for DSP: 'http://www.xilinx.com/apps/dspoview.htm' Xilinx DSP applications site: 'http://www.xilinx.com/apps/dsp.htm' Altera DSP applications site: 'http://www.altera.com/html/programs/ta_dsp.html' -- Steven Knapp OptiMagic(tm) Logic Design Solutions E-mail: sknapp @ optimagic.com Programmable Logic Jump Station: http://www.optimagic.comArticle: 6572
If you are attending the Design Automation Conference, don't miss DynaChip's demonstration of their Fast Field Programmable Gate Array. These unique FPGAs use Active Repeaters to propagate signals with extremely short routing delays. At the demo you will see: - Over 100 MHz system-level performance using HDL synthesis flows - Short, predictable routing delays that are not affected by fanout - Ultra high speed I/O structures that support up to 200 MHz clock and data - ECL, PECL and GTL interface levels Dates and Times: June 9, 10 and 11 at the Anaheim Convention Center Monday at 10:00 and Tuesday at 11:00 in Exemplar's Booth #852 Monday, Tuesday and Wednesday from 2:00 to 4:00 in Synopsys' Suite #D3418 For an appointment, send email to support@dyna.com or just stop by the sites listed above. You can get more information on the company at their web site http://www.dyna.comArticle: 6573
If you are attending the Design Automation Conference, don't miss DynaChip's demonstration of their Fast Field Programmable Gate Array. These unique FPGAs use Active Repeaters to propagate signals with extremely short routing delays. At the demo you will see: - Over 100 MHz system-level performance using HDL synthesis flows - Short, predictable routing delays that are not affected by fanout - Ultra high speed I/O structures that support up to 200 MHz clock and data - ECL, PECL and GTL interface levels Dates and Times: June 9, 10 and 11 at the Anaheim Convention Center Monday at 10:00 and Tuesday at 11:00 in Exemplar's Booth #852 Monday, Tuesday and Wednesday from 2:00 to 4:00 in Synopsys' Suite #D3418 For an appointment, send email to support@dyna.com or just stop by the sites listed above. You can get more information on the company at their web site http://www.dyna.comArticle: 6574
In article <5mvdit$mbh$1@news.nero.net>, Steen Larsen <steenl@pal.ece.orst.edu> wrote: >In article <5mjqq1$m3j$1@news01.btx.dtag.de>, HTD <Hans Dermot Doran> wrote: >>On Mon, 26 May 1997 20:47:42 GMT, stuart.summerville@practel.com.au >>(Stuart Summerville) wrote: >> >>>Hi all, >>> >>>I have a 208pin PQFP fpga (0.5mm pitch) on a board. I am having >>>problems with pin connections to the board. Attempting to re-heat the >>>solder to make a clean connection seems to create problems with >>>surrounding pins - it doesn't take much to get a minute solder bridge >>>between two pins. >>> >>>Two questions: >>> >>>1) Do any of you find such packages tend to come in with such >>>connection problems? >>> >>>2) What is the feeling about attempting to re-solder such pins if a >>>connection seems to be flakey? Am I wasting my time trying to fix it? >>>Maybe if some pins have flakey connections then others on the same >>>chip are likely to (eg. if some are bent down too much, then obviously >>>the others are at a different level...). >>> >> >Resoldering can be done, but I am no good at it. Sometimes the chip has >to be removed and the board traces will only handle 3-4 removals before >the traces separate from the board. > >The easiest solution for me was to go with the Altera 208PQFP socket since >I'm using an OTP FPGA. I use a hot-air gun with a small nozzle. Works great.
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