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 <5mn3hr$sv2@ftp.ee.vill.edu>, venkat@chaos.ee.vill.edu (K. S. Venkatraman) wrote: > Hi, > > I need some documentation sites on FPGAs, their uses, advantages etc. Can > anyone provide a resourceful URL? > > Thanks, > Venkat. I have two surveys on the uses of FPGAs in reconfigurable systems. They are available in the directory http://www.ece.nwu.edu/~hauck/publications/ The hardware/applications survey is mFPGAhard.ps or mFPGAhard.pdf The software survey is mFPGAsoft.ps or mFPGAsoft.pdf The PDF files are Adobe Acrobat, the PS files are postscript. Scott +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Scott A. Hauck, Assistant Professor | | Dept. of ECE Voice: (847) 467-1849 | | Northwestern University FAX: (847) 467-4144 | | 2145 Sheridan Road Email: hauck@ece.nwu.edu | | Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+Article: 6526
Relative to compliance: On the clock pin capacitance issue, Altera has tested and recharacterized the FLEX 10K products; errata will be published soon listing maximum at 12pF (within spec). On the two pin approach - agree. Trade-off Altera provides is 0-wait state pin-sharing design or 1-wait state single pin (fully compliant) design. Current MegaCore function went with performance. Future MegaCore function will provide 1-wait state single pin design and customers can certainly implement this functionality today. Since when did we officially become the boys in blue? Dave Greenfield Altera Corporation __________________________________ Stuart Clubb wrote: On Thu, 29 May 1997 20:29:00 GMT, aquantz@ibm.net (Aaron Quantz) wrote: >Ahhhh.. But if you have seen the news lately you'll notice the Altera >IS fully PCI compliant. The've just released a core product. If by a core product you mean the pci_a megacore function, then I am sorry, but I have to disagree. At: http://www.altera.com/html/products/mc-pci_a.html#comp They state compliance with REV2.1, yet list just 3 base parameters clk2q, setup, and 33MHz clock. I have seen no electrical checklist with a nice row of tick boxes. Read the documentation, it's only a megabyte of pdf. Then read the PCI spec. and compare. I refer you again to page 6 of dsdma_01.pdf from the literature section. Altera say they have two pins on three different PCI signals. The two pin approach undoubtedly breaks the spec of 10pF maximum load on a pin. The Altera solution gives a maximum 20pF, so they fail. Another spec requirement is for the clock pin to have sub 12 pF, Altera is listed as maximum 15pF. Fail again Altera is not compliant. Of course they could change their specifications, like they did with the EAB, that would be up to them. Until they do, and ship guaranteed product, the pci_a core cannot claim to be compliant. Of course, it_probably_works, but so does a 6 nS SRAM in a 5 nS design requirement, MOST OF THE TIME. Those who would choose to follow such dubious engineering practices do so at their own, and company's, risk. Anyone want to disagree? Still silence from the boys in blue. StuartArticle: 6527
Stuart Clubb wrote:
> Altera say they have two pins on three different PCI signals.
>
> The two pin approach undoubtedly breaks the spec of 10pF maximum load
> on a pin. The Altera solution gives a maximum 20pF, so they fail.
>
> Another spec requirement is for the clock pin to have sub 12 pF,
> Altera is listed as maximum 15pF. Fail again
>
> Altera is not compliant. Of course they could change their
> specifications, like they did with the EAB, that would be up to them.
> Until they do, and ship guaranteed product, the pci_a core cannot
> claim to be compliant.
>
> Of course, it_probably_works, but so does a 6 nS SRAM in a 5 nS design
> requirement, MOST OF THE TIME. Those who would choose to follow such
> dubious engineering practices do so at their own, and company's, risk.
>
> Anyone want to disagree?
>
>
How does Altera get away with such crap? Can't the PCI police put them
in jail for lying? Beware of companies which don't understand the
difference between a working implementation in the lab and a validated
implementation which meets worst case specs. If this is really their
attitude, it calls into question all of their 'guaranteed' specs. After
looking at the way they count gates and implemant benchmarks I'm
starting to detect a pattern here.
This is all they give you as far as compliance is concerned:
ALTERA> Table 3 describes timing elements for FLEX 10K devices that are
ALTERA> compliant with the PCI Special Interest Group's (PCI-SIG) PCI
ALTERA> Local Bus Specification, revision 2.1.
ALTERA>
ALTERA> Table 3. Timing Elements for the EPF10K30RC240-3 Device
ALTERA> Timing Element
Specification
ALTERA> Clock-to-output time 11 ns
ALTERA> Set-up time 7 ns
ALTERA> Maximum clock rate 33 Mhz
What ever the above means, it has very little to do with being legal on
the PCI bus. There are literally hundreds of specs and this tells me
only about the three that are legal. Maybe the following quote from
from
the licence agreement explains it a little better.
ALTERA> ALTERA DOES NOT WARRANT THAT THE FUNCTIONS
ALTERA> CONTAINED IN THE PROGRAMS AND MegaCore FUNCTIONS
ALTERA> WILL MEET YOUR REQUIREMENTS, OR THAT THE OPERATION
ALTERA> OF THE PROGRAMS AND MegaCore FUNCTIONS WILL BE
ALTERA> UNINTERRUPTED OR ERROR-FREE. YOU ALSO ASSUME
ALTERA> RESPONSIBILITY FOR THE SELECTION OF THE PROGRAMS
ALTERA> AND MegaCore FUNCTIONS TO ACHIEVE YOUR INTENDED
ALTERA> RESULTS AND FOR THE INSTALLATION, USE, AND RESULTS
ALTERA> OBTAINED FROM THE PROGRAMS AND MegaCore FUNCTION
Well it is free!
-
Brad
Article: 6528On Fri, 30 May 1997 21:39:50 -0700, Dave Greenfield <david_greenfield@altera.com> wrote: >On the clock pin capacitance issue, Altera has tested and >recharacterized the FLEX 10K products; errata will be published soon >listing maximum at 12pF (within spec). I thought you might. I guess that means the yield wil go down. **** SHAREHOLDER ALERT **** Does the price now go up, or will you make less money? >On the two pin approach - agree. Trade-off Altera provides is 0-wait >state pin-sharing design or 1-wait state single pin (fully compliant) >design. Current MegaCore function went with performance. Future >MegaCore function will provide 1-wait state single pin design and >customers can certainly implement this functionality today. Well there it is folks. I guess that we have now established that Xilinx and Lucent are capable of zero wait burst, fully compliant, today. The Altera MegaCore is not compliant, and indeed all FLEX10K devices shipping are not PCI compliant. >Since when did we officially become the boys in blue? An off-handed reference to the colour blue used on your Data book cover. I could make references to the witholding of evidence to gain a conviction (design?), but that would not be sporting would it? I believe Brad says it with a little more weight than I would. I guess that this pretty much wraps this thread up. StuartArticle: 6529
There is a comprehensive list of programmable logic vendors, design software, books, boards, consultants, etc. available on the Programmable Logic Jump Station. Check out 'http://www.optimagic.com' -- Steven Knapp OptiMagic(tm) Logic Design Solutions E-mail: sknapp @ optimagic.com Programmable Logic Jump Station: http://www.netcom.com/~optmagic K. S. Venkatraman <venkat@chaos.ee.vill.edu> wrote in article <5mn3hr$sv2@ftp.ee.vill.edu>... | Hi, | | I need some documentation sites on FPGAs, their uses, advantages etc. Can | anyone provide a resourceful URL? | | Thanks, | Venkat. |Article: 6530
On Thu, 29 May 1997 07:03:31 GMT, "Jye Mei Ng" <Jye=Mei=Ng%Port=Eng%Eng=Sin@netgate.compaq.com> wrote: >Sorry if this is ask before, I'm new to this group. I'm currently a student >and am interested to know which is better. Especially for the application >to PCI,ISA connections. I think that we have just established the PCI bit in another thread: Xilinx is capable of full PCI implementation with zero wait burst, fully compliant. You will need to design it yourself. The Xilinx offered core runs at half burst speed. Altera FLEX10K is not PCI compliant. Specs will change to enable half burst speed. Full burst will not, on current information be PCI compliant. Lucent Technologies also offers a fully compliant PCI solution at full burst rates. Your proven choice so far is therefore Xilinx or Lucent. As for ISA bus, that's pretty straightforward for all I guess, but it would depend on your back-end logic requirements as to who you decided to use. StuartArticle: 6531
Should be, by implementing a simple state machine which just does what you would do in software. >Is it possible? Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 6532
FS: CADKEY '97 -100+ Available- Save $HUNDRED's EACH!!! Hello! A new copy of Cadkey 97 is selling on the street for $1,195. To guarantee updates for the next year costs $350 more, bringing it up to $1,545 total! We have available over 100 NEW unopened, shrinkwrapped copies of Cadkey 6.0 on CD for DOS which can be upgraded to Cadkey 97, INCLUDING the year's worth of free updates, for the street price of $595; that's $950 less than the normal street price! Or, maybe Cadkey 6.0 has enough power for you with no upgrade at all! (Cadkey '97 is basically Cadkey 8.0) I'm selling these for best offer, one or all. If you would like more info on Cadkey 97, here's Cadkey 97's Web page: http://www.cadkey.com/cadkey/index.htm Thanks! Karl KristiansonArticle: 6533
Peter <z80@dserve.com> wrote in article <33956660.159142955@news.netcomuk.co.uk>... > Should be, by implementing a simple state machine which just does what > you would do in software. > > >Is it possible? > One problem that you will have to solve is the fact that DIN on the Xilinx (in serial mode) is also connected to D0 on your FLASH part. It would seem that you would need to use some handshaking back to your downloader to indicate when you are driving the line during the flash program cycle verses when you are listening for more data in the receive mode. Since the INIT pin becomes an I/O after configuration and it is connected to the XCHECKER cable this would seem to be a reasonable choice. An alternative might be to add a jumper between DIN on the Xilinx and D0 on the flash, and add a second pin from D0 on the flash to an I/O on the xilinx. During normal operation, the jumper is installed and the xilinx boots from the flash. During your download/reprogram mode, remove the jumper. DIN on the Xilinx is driven from the download cable and D0 on the flash is driven from the Xilinx I/O pin. At this point you could have a state machine receive data serially, buffer it up using Ram in the part and then program the FLASH in parallel mode. The next question seems to be more to the point. Can the XCHECKER cable be used in this function? My GUESS is that it can't in it current configuration. You may have to create your own downloader cable/circuit that can shift into a serial data transfer mode after the target has been loaded with a boot configuration. This would be a neat way to reconfigure parallel flash mounted to a board without alot of additional circuitry. It could also be used for reconfiguring serial flash proms from Atmel. John john_mcgibbon@memecdesign.comArticle: 6534
Dear John Thank you for your reply. I first thought, that this is one of these "dead" usergroups, which eat up only space on the servers. Your (second in all) reply taight me different. > During normal operation, the jumper is installed and the xilinx How about a combination of your suggestion: I could use XC4000's RAM to store a portion and then program the Flash with it. The jumper is a concern, but I could use a 1..5K resistor between Xchecker to overcome this. > You may have to create your own downloader cable/circuit Do you know what it really does? I looked at it, and it was filled with CPLD etc. > This would be a neat way to reconfigure parallel flash mounted to a board without alot of additional circuitry. actually I would need a resistor only, which I planned anyway, because of the protection of the XC4000. Another question is: Is it possible to send data FROM the XC4000 through the XChecker TO the PC?? Thank you again for your reply. Your Jimmy D. download it then I could I canArticle: 6535
Nothing hidden here! Let me see, I signed my name, my company name is in my domain name, both my name and my company's name are in the phone book, and the POP I connected from is listed right in the email. What's wrong with being the sales engineer here? Aren't you a QL employee? Aren't we all involved in this industry? The issue isn't who works for who, but what's in the summary judgement - and therefore, who owns what. That isn't mud slinging, its a fact and now a matter of public record. How is that mud slinging? What's your problem? If you've got something to say on this case, I'd be interested in hearing it. This court case is complex, but interesting and worthy of discussion. If you want to make personal attacks, I guess I'd consider that a waste of time. But, if that's the image you want to project for you and your company, I guess that's your business. Regards John Sievert Customer 1st, Inc. <Blair@QuickLogic.com> wrote: > In article <19970526224329123272@cust4.max1.minneapolis.mn.ms.uu.net>, > john@customer1st.com (John Sievert) wrote: > > > > Technology, which it appears, probably came from Actel (per summary > > judgement against QuickLogic on patent infringement.). > > > > <kevintsmith@compuserve.com> wrote: > > > > > In this case, it's not marketing hype, just superior > > > technology. > > > > -- > > Regards, > > John Sievert > > Aren't you the Actel Manufacturers Rep in the MN area? > > It would behoove you to not sling mud and try to hide your identity. > > Regards, > Ben Blair > Manager Field Applications > QuickLogic Corporation > > -------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet -- Regards, John SievertArticle: 6536
Hi there ! Still in search of a way to incircuit program a parallel flash device with using the Xchecker. As the bigger (i.e. 4MBit or 8MBit) flashs have a JTAG prot, would it be possible to program them through that? Has anybody done JTAG on XC4000? CU Jimmy D.Article: 6537
Phani Putrevu wrote: > > Hi, > > I was wondering if there are a class of circuits/systems that I should > not implement using FPGAs. I am told that floating point units dont > perform well when implemented using FPGAs. In fact a multiplier that I > had implemented required 200ns (16 bit). Present day CPUs have much > better FPUs/ALUs. > > There was some discussion abt implementing comparator using FPGAs, and > some suggested use CPLDs for combinational logic. Are there any other > thumb rules as to when to go for an FPGA and when not to. > > This becomes important when you are considering co-design and you want > to decide if a function is to be executed in h/w or s/w. I have seen > systems where this is specified as a part of the input code. > > Thanks a lot. > > Phani > ------------------------------------------------------------------------ > Phani K Putrevu 384 Probasco Street #14 > MS - Comp Engg Cincinnati OH 45220 > University of Cincinnati Ph : 513-281 1154 (res) > email: pputrevu@ececs.uc.edu 513-556-0904 (lab) > URL : http://www.ececs.uc.edu/~pputrevu > ------------------------------------------------------------------------ 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). Reiner HartensteinArticle: 6538
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. > .... > (DRAFT) REQUEST FOR DISCUSSION > > Group Name: comp.arch.rpu > Status: unmoderated > Distribution: world wide > Summary: Discussions related to reconfigurable computing systems > Proposed by: Michael J. Alexander (alexander@eecs.wsu.edu) > > This is a formal Request For Discussion (RFD) on the creation of an > unmoderated newsgroup, comp.arch.rpu > ... =============================================================================== 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.deArticle: 6539
djimm2@aol.com (Djimm2) wrote:
:Hi there !
:
:Still in search of a way to incircuit program a parallel flash device with
:using the Xchecker.
:
:As the bigger (i.e. 4MBit or 8MBit) flashs have a JTAG prot, would it be
:possible to program them through that?
:
:Has anybody done JTAG on XC4000?
:
I have used XC4000 JTAG: it works well. I used a setup whereby the
XC4000 was configured (via JTAG) to look like a shift register &
counter, & used that to program the flash. Then reset the board, & the
FPGA self-configures from the flash, & runs.
BTW who makes those Flash parts you mention, the ones with a JTAG
port? I have wanted such a thing for many a year...
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
"From" line rigged to foil spambots: daveb <at> iinet.net.au
Article: 6540Reiner Hartenstein wrote: > > 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. > > .... > > (DRAFT) REQUEST FOR DISCUSSION > > > > Group Name: comp.arch.rpu > > Status: unmoderated > > Distribution: world wide > > Summary: Discussions related to reconfigurable computing systems > > Proposed by: Michael J. Alexander (alexander@eecs.wsu.edu) > > > > This is a formal Request For Discussion (RFD) on the creation of an > > unmoderated newsgroup, comp.arch.rpu > > > ... > =============================================================================== > > I appreciate your efforts. I would propose, that you establish this > group. > > Please, do not hesitate. > Best regards > Reiner Hartenstein http://xputers.informatik.uni-kl.de I'm all for this effort. This is like a split of the software/systems types from the hardware/systems types. It is a very natural outcome created by growth in the industry. The difference between two type can be debated but they exist and should be addressed. Comp.arch.fpga is nothing like I thought it would be when we first started. It never will be, but hey it does say FPGA and FPGAs are hardware and the CAE tools to implement them with. RPUs are processing units, most of which use FPGAs today. To use them you have to write programs for hardware and software objects. Its a different world and needs its own place. I vote yes! -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 6541
A while back I reported on problems with some EECAD apps running under NT4 SP2, specifically with memory leaks that caused the application to crash. The same apps worked just fine under Win95. [SP2=Service Pack 2, an OS update] I'm reporting now that the same apps now work just fine with NT4 SP3 installed. Robustness is greatly improved. If you are still running SP2, I strongly suggest you check out SP3. I've been running SP3 for about 2 weeks. Also, Netscape Commonicator 4 Beta 4 and 5 are both much more robust with SP3 installed. Hope this helps, my friends. -- Bob Elkind **************************************************************** Bob Elkind mailto:eteam@aracnet.com 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ****** Video processing, R&D, ASIC, FPGA design consulting *****Article: 6542
Dear all Altera CPLD designers (Professonals, students, hobbyists, professors, FAEs) I have set up a web site for you - the FreeCore Library - which is available at http://www.acte.no/freecore Everything you find here is free - including free function modules for use in your next project. Q: Who is behind the FreeCore Library? A: YOU ARE! This site will grow as you submit your functions to share with other designers! If you've done anything useful in Altera programmable logic that you would like to share with the rest of us - please send it to me! Best Regards, Rune BaeverrudArticle: 6543
In article <3391459D.3211@aix6.rhrk.uni-kl.de>, Reiner Hartenstein <hartenst@aix6.rhrk.uni-kl.de> writes >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. >> .... >> (DRAFT) REQUEST FOR DISCUSSION >> >> Group Name: comp.arch.rpu >> Status: unmoderated >> Distribution: world wide >> Summary: Discussions related to reconfigurable computing systems >> Proposed by: Michael J. Alexander (alexander@eecs.wsu.edu) >> >> This is a formal Request For Discussion (RFD) on the creation of an >> unmoderated newsgroup, comp.arch.rpu >> >... >=============================================================================== > > I also appreciate your efforts. I would back you up considering this is most definitely the way of modern computers in the future. Gareth BaronArticle: 6544
> > Altera FLEX10K is not PCI compliant. Specs will change to enable > half > > burst speed. Full burst will not, on current information be PCI > > compliant. > 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. JacArticle: 6545
alexande@eecs.wsu.edu (Michael Alexander - EECS) writes:
>
> Reconfigurable Computing Enthusiasts,
>
> I would like to solicit preliminary input on the following (draft) proposal
> for creating a newsgroup devoted to reconfigurable computing.
I'm all for it.
> 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.
This should be reflected by a change to the c.a.fpga charter also.
> 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.
I hope that RPU is not already used for some specific product. If it
is, c.a.reconfig or some such seems more appropriate.
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: 6546<<<Posted to c.a.fpga, and news.groups, with a courtesy copy (Cc:) to the quoted author>>> 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. > 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. > In order to keep the discussion open to everyone, please post any > comments to Comp.arch.fpga > Thanks, > --Mike Alexander > | (Draft RFD also at http://www.eecs.wsu.edu/~alexande/draft_rfd.html) | > =============================================================================== > (DRAFT) REQUEST FOR DISCUSSION > Group Name: comp.arch.rpu > Status: unmoderated > Distribution: world wide > Summary: Discussions related to reconfigurable computing systems > Proposed by: Michael J. Alexander (alexander@eecs.wsu.edu) > This is a formal Request For Discussion (RFD) on the creation of an > unmoderated newsgroup, comp.arch.rpu > 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. > Appropriate topics include, but are not limited to, programming tools, > languages and systems that support dynamic configuration; reconfigurable > processing architectures and RPUs, both commercial and research; and > applications of reconfigurable computing. > 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). > Until quite recently, reconfigurable computing has meant computing systems > built from FPGA devices. However, a new generation of FPGA-like devices, > which are often called reconfigurable processing units (RPU), support > key features such as partial fast reconfiguration. RPUs enable a new > computing paradigm based on ``virtual hardware'', where application-specific > hardware is time-multiplexed on the RPU in order to meet adaptive computing > requirements. Reconfigurable computing systems are hardware/software systems > in which hardware functionality is not fixed a priori, but rather is tailored > at runtime to meet application computational requirements. > It appears from its charter that Comp.arch.fpga was intended to be a > vehicle for discussing FPGA-based computational engines and systems such as > those that have appeared at the IEEE workshops FCCM 93-97. Discussions > on Comp.arch.fpga focus largely on the use of FPGA CAD tools and design > techniques, which are extremely useful to the general, larger FPGA-design > community. Rather than ``reclaim'' Comp.arch.fpga as the proper domain > to discuss reconfigurable computing, it would be most beneficial to allow > Comp.arch.fpga to maintain its current function (as the proper discussion > place for FPGAs) and introduce a new group, Comp.arch.rpu, devoted > to discussing the use of reconfigurable processing units. > =============================================================================== 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 (other than a few alarm and control leads connecting to an alarm filtering and processing CPU). I think it would be wrong to keep general-purpose posts here. (Then again, I think much of comp.dcom.telecom.* should really be in sci.engr.electrical, with the exception of stuff like modems, lans, etc.) 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. I am sure you are also aware that for your RFD to really make it to formal RFD status, you will have to add more legalistic boilerplate and format it in accordance with David Lawrence's FAQ on rules for formatting RFDs, which you can probably find in news.answers or on the rtfm.mit.edu FAQ archives. -- R. T. Wurth / (w) Holmdel, NJ / (h) Rumson, NJ rwurth@att.comArticle: 6547
> Iakovos Stamoulis <I.Stamoulis@Sussex.ac.uk> writes: > > > Altera FLEX10K is not PCI compliant. Specs will change to enable > > half > > > burst speed. Full burst will not, on current information be PCI > > > compliant. > > > 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. > > Jac > > >>>> 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. Regards Uffe Tyrsted Toft ------------------------------------------- ACTE NC Denmark A/S E. V. J. Elektronik Titangade 15 DK 2200 Copenhagen N Phone: +45 35 86 90 22 Fax: +45 35 86 90 00 E-mail: evjapps@inet.uni-c.dk -------------------------------------------Article: 6548
> hgw@cssmuc.frt.dec.com (Hans-Guenther Willers) writes: > Hi All! > > has someone done an I2C slave interface in a HDL (AHDL, VHDL, > Verilog)? > > > > Greetings, > > Hans-Guenther Willers (is hgw@frt.dec.com) > > >>>> Take a look on the following homepage. You will find an I2C bus controller a.o. http://www.acte.no/freecore Regards Uffe Tyrsted Toft ------------------------------------------- ACTE NC Denmark A/S E. V. J. Elektronik Titangade 15 DK 2200 Copenhagen N Phone: +45 35 86 90 22 Fax: +45 35 86 90 00 E-mail: evjapps@inet.uni-c.dk -------------------------------------------Article: 6549
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
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