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
richw@lsid.hp.com (Rich Wilson) writes: >bgeer (bgeer@xmission.com) wrote: >I did, however, find a very serious problem with the part itself, which >they don't seem willing to talk about. I was originally planning to >run the system at 80MHz, and found that the parts, under certain >conditions, just plain don't go that fast. Apparently the internal >feedback drivers are too wimpy, and if a signal gets fed back to too >many CFBs, it doesn't meet spec. By bringing the lazy signal out >to an output pin via an unused output, I could make a direct Tco2 >measurement. The spec is 16nS; I was measuring 17.2nS at room >temperature at one point. Before I used the workaround (see below), >I even saw failures at 64MHz. >If I can believe Intel, I am the first person to report this behavior, >and they were not aware previously that there might be a problem. >They have NOT been responsive to telling me how they intend to >rectify this shortcoming. Funny that you mention it, I just had a similar experience in a experimental design that refused to work at 80 MHz, but was fine with 64. >From reading the datasheet, I suspect there might me some truth in your suspicion: Intel specifies 100 MHz for forward signal paths, but only 80 for feedback Paths. To me, this indicates the form of limitation you are talking about. To any intel folks that listen: Please don't understand me wrong, I just Love the iFX devices; They are the finest piece of SW/HW regarding Price/performance. Too bad the business is sold off to Altera. I expect the Price/performance ratio for new devices to drop below acceptance level for us. \Peter -- Peter Averkamp, | email: Physics Department E20 | petav@radon.e20.physik.tu-muenchen.de Techn. Univ. of Munich | Phone: ++49 (89) 3209-2408 and -2814 D-85748 Garching, Germany | Fax: ++49 (89) 3209-2338Article: 51
Has anyone out there used Field Programmable Interconnect. I recently read something about Aptix programmable interconnect and it seems it could be of use. Therefore can anybody answer the following? 1. Is the development system expensive 2. Easy to use? 3. Are there other products? Liam Marnane Dept of EE University College Cork Ireland email:marnane@iruccvax.ucc.ieArticle: 52
Robert Proffitt (proffitt@mdd.comm.mot.com) wrote: : Ok, A design I was part of used 14 Altera MAX devices to build : a superclone of the RCA 1802. We called it the 18020. : This design was then exported to workstations and then built : into custom ASICs. All in all a great experience! You've got to be kidding! Who in the world would like to use a 1802-derived CPU today? Is it for satellite use maybe? Astonished / Krister --- Krister Lagerstrom (Undergrad. CEng student) Email: ksla@mtek.chalmers.se Uppstigen 126-81 d2ksla@dtek.chalmers.se 412 80 Gothenburg SWEDEN Phone: +46 31 778 43 61Article: 53
Hi, I'm designing with the Intel iFX family of CPLDS and have a few questions. 1) Is anyone willing to give me the e-mail address of a good support person at Intel? 2) Does anyone have experience using the iFX evaluation board (Part # EVFX780US) or the prototyping cable kit (Part # EVFX780CBL)? 3) I noticed that the AC specs on the data sheet are referenced to a 1.5 V test point, not to Vih or Vil. Is this just specmanship to make the tCO1 spec lower (i.e. it takes less time to get to 1.5 V than down to 0.8 V)? Cheers, -- Jim Tompkins Internet : tompkins@appliedmicro.ns.ca Applied Microelectronics Institute Voice : (902) 421-1250 1046 Barrington Street Fax : (902) 429-9983 Halifax, NS CANADA B3H 2R1Article: 54
Hi. I've read through the comp.lsi.cad FAQ and looked at various other sources, and I have some questions left unanswered. First, I'd like to know the costs of manufacturing a sea-of-gates or other PGA design. I am not currently considering such fabrication, but I'd like to know more about it. I'm planning on playing with FPGA's and because I'm just starting, I think I'll go for the Intel (soon Altera) iFX chips. I've heard some people complain that these are not true FPGA's. Could someone explain their limitations to me? Thanks in advance, Ken GeisArticle: 55
In article hadlich@csmd.cs.TU-Magdeburg.DE (Thomas Hadlich) writes: >Hello, > >I'm having problems with my mouse when I start MAKEBITS from XDE. Somehow >the program recognizes my mouse as a XCHECKER cable. Thus I can't use my >mouse. I already tryed the 'port' command, and to save a proper configu- >ration in the profile, but that doesn't help. >Somehow the problem can be fought by moving the mouse when starting >MAKEBITS. But that works only in 2 of 3 cases. And I feel really stupid >jerking around while starting a program.. :) > > >I'm not quite sure if this is the right place to ask, but I know no >better place.. > >If you can help me please answer by pm. > >Thank you > > Thomas Hadlich This is a bug in XACT/MAKEBITS. Makebits detects the serial port used by your mouse, and thinks it is a bitstream download port. The serial port is reconfigured by MAKEBITS, making your mouse inoperable. The workaround is to disconnect your mouse from the serial port before you invoke MAKEBITS under XACT. When you are in MAKEBITS, you can go ahead and reconnect your mouse. Since I invariably do manual place and route editing, I invoke the "makebits" command from within the EDITLCA editor, and avoid the MAKEBITS program entirely. All this is rendered moot by version 5.0, which I have not had the (guts) to try yet. Bob Elkind, Tektronix TV bobe@tv.tv.tek.comArticle: 56
In article <tompkins.776011314@appliedmicro.ns.ca>, tompkins@appliedmicro.ns.ca (Jim Tompkins) writes: |> |> Hi, |> |> I'm designing with the Intel iFX family of CPLDS and have |> a few questions. |> |> 1) Is anyone willing to give me the e-mail address of a good |> support person at Intel? |> |> 2) Does anyone have experience using the iFX evaluation board |> (Part # EVFX780US) or the prototyping cable kit (Part # EVFX780CBL)? |> |> 3) I noticed that the AC specs on the data sheet are referenced |> to a 1.5 V test point, not to Vih or Vil. Is this just specmanship |> to make the tCO1 spec lower (i.e. it takes less time to get to |> 1.5 V than down to 0.8 V)? I've got a fourth question: 4) Is Altera committed to continue development and production on the iFX parts or are they planning to raid the facilities and orphan the parts? -- Scott ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Scott Gargash Email: scott@plab.dmll.cornell.edu 009 Morrill Hall Phone (607) 255-0708 Cornell University Consultant/Advisor Ithaca, NY 14853 DMLL - Phonetics LaboratoryArticle: 57
In article <31rbme$8t0@news.tv.tek.com> bobe@soul.tv.tek.com (Bob Elkind) writes: >This is a bug in XACT/MAKEBITS. Makebits detects the serial port used by >your mouse, and thinks it is a bitstream download port. The serial port >is reconfigured by MAKEBITS, making your mouse inoperable. I have run into the additional bonus that while MAKEBITS thinks the mouse is download cable, and conveniently disables it, he also doesn't allow me to us my parallel download cable hooked up to LPT1! Don't ya' just love 'em? >The workaround is to disconnect your mouse from the serial port before >you invoke MAKEBITS under XACT. When you are in MAKEBITS, you can go ahead >and reconnect your mouse. >Since I invariably do manual place and route editing, I invoke the >"makebits" command from within the EDITLCA editor, and avoid the MAKEBITS >program entirely. >All this is rendered moot by version 5.0, which I have not had the (guts) >to try yet. We tried it, but don't have the answer to the MAKEBITS question. Do you think that they fixed it? I have found that I have to convert my old designs, as they have removed the OINV function from their libraries. Can't figure out why. They haven't changed the chip, you can still invert the output in an IOB. For some reason however, they now force you to put in an INV and an OBUF. Not a big deal, just a PITA.Article: 58
I'm also interested in the possibility of using FPGA's for a homebrew project. Although I haven't worked through the detailed design yet, I reckon it will require several square feet of PCBs full of TTL chips. I got hold of a copy of Intel's PLDShell Plus, but I'm not sure that the FLEXlogic chips are going to be much help for building the binary interpolaters and multipliers I need for my design. I'm curious about the TI TPC10xx series FPGAs, as a number of suppliers list these (including Maplin Electronics, which targets the hobby market). However, only Farnell list the development software and, and it's marked ``POA''. Now in my experience, when something is marked POA, it means ``This is so expensive that if we printed the price, you wouldn't even think of buying it''. Does anyone know if my suspicions are correct? I'd be interested to know if there is any reasonably-priced ( < GBP 100) development software for the TPC10xx series (or any other FPGA's). Also, if the devices are in-circuit configurable, or if there is the neccessary information to build a programmer (or a cheap kit is available). I find it difficult to understand why the chip manufacturers' development software is so expensive. After all, they are in the business of selling HARDWARE. They obviously have to have the software anyway, for testing purposes. I would imagine that the revenue from a highly-priced development tool is miniscule compared to that from selling the chips. If they can make their software available cheaply (or even on an Anon FTP server, like Intel) many people who would never consider buying a highly-priced package, they might just sell more chips. Perhaps I've spent too much time hacking Unix, and I've come to expect that you can get virtually any item of software (operating systems, compilers, databases etc) in source code form for free. However, as far as I'm concerned, the bottom line is this: The manufacturer is making a product to sell. I would like to buy and use that product, for which I need technical information and/or development software. I am quite prepared to pay for the information or software, provided the cost doesn't exceed that of a couple of the chips. To me, comprehensive technical documentation is not far removed from advertising, and I don't expect to pay much more than the cost of production. Finally a point to ponder. When I was a student about 20 years ago, TTL chips were pretty well state of the art. You could buy them quite easily, you could get hold of the manufacturers' data books, and armed with not much more than a home-made logic-probe and a large amount of persistence and low cunning, you could build things like digital clocks. This was the time when a commercially-built ``digital clock'' generally contained an electric motor and a lot of gears which turned drums with numbers printed on them. When you had built your TTL alarm clock or whatever you almost certainly felt a great sense of achievment, as you had got something which it was difficult (if not impossible) to buy at that time. Inevitably, the increasing use of custom chips and PLDs will lead to a reduction in the range of MSI and SSI devices, and possibly a significant increase in their cost. If PLD development tools are priced out of the reach of the keen amateur, digital electronics as a hobby is on its way to dying out. Why should the electronics industry worry about this? Well I suspect very few people wake up one morning and decide to register for a degree in electronics. Most of them become electronic engineers because of a long standing interest in electronics. The kind of person who will become a highly talented engineer (once he or she has got past the elementary stage of building amplifiers that oscillate and oscillators that don't) will want to build something difficult and state-of-the-art. Glancing through Tracey Kidder's ``The Soul of a New Machine'' the other night provided ample confirmation of this, including one engineer who had built an FPU while in college. If PLD manufacturers continue to price their development tools out of the reach of the individual hobbyist, it may be an effective way of persuading a lot of talented people that their future lies in some field other than digital electronics. I would like to echo the earlier call for low-cost unsupported, no-frills software. Roger -- ------------------------------------------------------------------------------ Roger Brooks, Systems Programmer, Computing Services Dept, | rsb@liv.ac.uk The University of Liverpool, PO Box 147, Liverpool L69 3BX | +44 51 794 4441 ------------------------------------------------------------------------------Article: 59
By popular request I am starting a WWW page of links to FPGA related
WWW Pages. It will be a lot like the LSI/VLSI WWW page at URL:
http://www.mrc.uidaho.edu/vlsi/vlsi.html
If you have information on URL's of applicable pages please email me.
Thanks,
Len
_______________________________________________________________________
| __ ___ ___ _______ _____ |
| /| | /\ \ /| \|\ _ \/\ __\ Len Harold |
| | | | \ \ - | \ \ \_\ /_ \ \_/ |
| | | \ \ \ \ _|\ \ \ _ \ \ \___ Phone: 208-885-7034 |
| | | \ \ \__\/\ \__\ \__\ \__\ \_____\ Fax: 208-885-6840 |
| | |* | \/__/ \/__/\/__/\/__/\/_____/ Internet: |
| |/\ |/\ lharold@uidaho.edu |
| \/ \_/\ University of Idaho |
| /| | Microelectronics Research Center |
| | | | NASA Space Engineering Research |
| | |____________| Center for VLSI System Design |
| |/____________/ WWW[URL]: http://www.mrc.uidaho.edu/ |
|_______________________________________________________________________|
Article: 60Chuck Corley (chuckc@sr.hp.com) wrote: : Um, OK, given your posting, maybe you or someone else can clue : me in to a few things: : 1) I was under the impression that the "fpga" in "comp.arch.fpga" : stood for "Field Programmable Gate Array", such as the devices : made by Xilinx, Actel, AMD, Lattice, Altera, etc. (I apologize : for any companies I missed). : Why did you post an article about a supercomputer here? Does this : supercomputer use FPGAs? Or is there another meaning to FPGAs : that I'm not aware of? Or did you just post this so that you : could claim to be the "first poster"? I'm kind of surprised that the proponent for this group didn't repost the charter here. It is comp.ARCH.fpga and is (as I remember the discussion in news.groups) about supercomputers that are implemented using reconfigurable logic. After reading this first week or so's traffic, it looks like they're going to be sorry that they didn't create something like comp.lsi.fpga at the same time (or before). Oh well, such is USENET. Mark Zenier mzenier@netcom.com mzenier@eskimo.comArticle: 61
Scott Gargash (scott@plab.dmll.cornell.edu) wrote: : I've got a fourth question: : 4) Is Altera committed to continue development and production : on the iFX parts or are they planning to raid the facilities : and orphan the parts? In a Q&A FAX that Intel sent to their customers, they stated that the iFX730 and the IFX760 were not going to be developed. IMHO this means that Altera will sell what already exists and blow off future development of this architecture. After all they have two CPLD families (MAX5000 & MAX7000) and an SRAM based FPGA (FLEX8000) right now; they have said they will introduce a new CPLD family at the end of this year - Why bother with continued development of the Intel stuff when what they really wanted out of the agreement was .5u Wafers... -- Mark Aaldering mma@einet.comArticle: 62
In article <mzenierCu3Gxp.GBs@netcom.com> mzenier@netcom.com (Mark Zenier) writes:
I'm kind of surprised that the proponent for this group didn't repost
the charter here. It is comp.ARCH.fpga and is (as I remember the
discussion in news.groups) about supercomputers that are implemented
using reconfigurable logic.
After reading this first week or so's traffic, it looks like they're
going to be sorry that they didn't create something like comp.lsi.fpga
at the same time (or before).
I did repost the charter as a followup to the original "froup"
message, but here it is again (from the Call For Votes):
Newsgroups line:
comp.arch.fpga FPGA based reconfigurable computing systems.
CHARTER
The unmoderated newsgroup comp.arch.fpga will be open to discussions on
all topics related to the use of reconfigurable Field Programmable
Gate Arrays (FPGAs) as computational engines. Appropriate topics
include, but are not limited to,
system architecture
FPGA device architecture
languages and compilation techniques
tools
software environments
applications
Note: this newsgroup grew out of a mailing list called
"info-fpga-computing" which has been active since the fall of 1992,
and the two IEEE Workshops on FPGAs for Custom Computing Machines
(FCCM '93 & '94). The archives of that mailing list, the discussion
on the creation of this newsgroup, and other interesting topics
related to FPGA based computing can be found in
ftp://super.org/pub/www/FPGA/info-fpga.page
When I get around to it, the archive of this newsgroup will be there
as well. And please let me know if you have suggestions for this page.
-jeff
------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org
Article: 63
On 28 Jul 1994 16:23:01, mlindste@csugrad.cs.vt.edu (Red Sleepy) writes:
>
> The SPLASH is pretty flaky from what I understand. I'm a senior at Virginia
> Tech and we have the thing. It only works sometimes, who knows why.
>
> Anyway, the SPLASH is almost completely XILINX chips, and lots of them.
> It's in Dr. Armstrong's advanced computer design research lab, but somebody
> else Dr. Athas uses it for visualation and other things.
>
Hmmm... being a graduate student at Virginia Tech, this really troubles me.
I have been a member of the VT Splash team for a full year, and I can't say I
quite agree with this entire posting (hence this reply).
Webster's dictionary defines "flaky" as "distinctly and often amusingly
eccentric". Furthermore, "eccentric" is defined as "deviating from an
established pattern or from accepted usage or conduct." Does Splash follow
this definition? I think it just might.
Our Splash 2 system at Virginia Tech does deviate from the established pattern
of computing platforms. We have turned an off-the-shelf Splash-2 system into
a real-time image processing computing platform capable of performing some
pretty complex tasks:
----------------------------------------------------
Current real-time video image processing tasks
(30 frames/second, 512 x 512 greyscale resolution)
----------------------------------------------------
+ Grey-scale histogram generation
+ Region detection and labeling
+ Image pan and zoom
+ 8 x 8 window convolution
+ 2-D Fast Fourier Transform (floating point)
+ 24-tap FIR filter communications channel model
+ Object profile classification
+ Median filtering
+ Morphological operations (i.e. erosion and dilation)
+ Laplacian-of-Gaussian pyramid generation
+ Hough transform for straight lines
+ Sobel edge detection
+ many, many more
So, you see that Splash seems to do *some* work. Granted, it doesn't sing or
tap-dance 24 hours a day, but it does get used quite extensively. So, does
this finally put Splash-bashing to rest?
> Anyway is it really all that intellegent to rely on FPGA's for an entire
> computer? I don't know much about FPGA's so please don't flame me.
I think that research in the usage of FPGA's as computing devices
is a very good thing. For one thing, I believe it breaks us (as engineers and
scientists) away from the tendency to think of computer hardware as
something "fixed" or "unchangable". Reconfigurable hardware has been proven
to be beneficial in many areas such as image and signal processing, pattern
matching, and other bit-wise computationally intensive tasks. However, we have
a lot of developing ahead of us (i.e. compilers, architectures, etc.) before
we are ready to move into an "entire computer" based on FPGA's. This is why
*research* projects like Splash-2 are not a waste of time, but a valuable
learning tool which will enable us to define new paradigms for future
computing platforms.
> opps, Dr. Athas supposed to be Dr. Anthas.
>
> just in case anybody is interested in SPLASH.
>
Dr. Athanas would be perfectly willing to further describe
^^^^^^^
any of the work currently being done on Splash-2 and other
reconfigurable computing projects at Virginia Tech. Please send
e-mail to athanas@pequod.ee.vt.edu for more details.
- Brad
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
Brad Fross |
EE Graduate Student | Space for rent.
Virginia Tech |
fross@super.org |
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Article: 64In article <Cu2psC.DwE@liverpool.ac.uk>, rsb@liverpool.ac.uk (Roger Brooks) writes: > I'd be interested to know if there is any reasonably-priced ( < GBP 100) > development software for the TPC10xx series (or any other FPGA's). Me too. > > I find it difficult to understand why the chip manufacturers' development > software is so expensive. After all, they are in the business of selling > HARDWARE. If only 'twere so. The fact is that Xilinx probably owes a good portion of it's sales revenue to selling software (at approx. $8000 a pop for a basic workstation configuration, 4-5K for PCs) and selling the right to write software for their devices to third party vendors. I suspect that most other FPGA makers are either in a similar situation or rely on third party tools produced by companies whose sole business is selling CAD software. In the case of Xilinx, they realize this and do all they can to make sure that market doesn't slip away from them. The fact is, it wouldn't be all that hard to write an APR/PPR type tool (perhaps missing some of the bells and whistles of the Xilinx software, but perfectly usable) and a downloader. I already know of a free HDL targeted toward Xilinx fpgas, namely SOLDER from the Anyboard project. There may be others, such as the LISP-like language used in a previous version of the SPLASH project. However, Xilinx keeps the .bit format (the mapping between the download bit stream and the bits in the logic blocks in each of the CLBs, the multiplexor configuration bits, the SRAM cells that drive the transistors in the routing matrix and so on) a deep, dark secret. I've tried to get it and had the powers that be in the school I was in at the time try to get it, and both times was turned down flat. I've thought of trying to reverse engineer the format using the Xilinx tools and got far enough along to realize what a big job it is (too much for the grad student I was at the time to fit into his schedule). In addition, I'm uncertain about the legalities involved (is it possible to copyright or patent a file format?). Xilinx has had the lion's share of the attention so far as SRAM based fpgas go. Does anyone know of a company that manufactures SRAM based fpgas that also has a cooperative enough attitude that they'll release sufficient technical data to make it possible to write freely available tools like place and route software? -- ----------------------------------------------------------- Douglas Thomae thomae@trantor.harris-atd.com (407) 729-7253 Advanced Technology Dept., Harris Corp.Article: 65
In article <Cu2psC.DwE@liverpool.ac.uk> rsb@liverpool.ac.uk (Roger Brooks) writes: >I find it difficult to understand why the chip manufacturers' development >software is so expensive. After all, they are in the business of selling >HARDWARE. They obviously have to have the software anyway, for testing They have to pay the people to answer the phone when users of their software have questions... -- Good bye, Mr. Roberti. Thanks for playing.Article: 66
rsb@liverpool.ac.uk (Roger Brooks) writes:
>I find it difficult to understand why the chip manufacturers' development
>software is so expensive. After all, they are in the business of selling
>HARDWARE. They obviously have to have the software anyway, for testing
>purposes. I would imagine that the revenue from a highly-priced development
>tool is miniscule compared to that from selling the chips. If they can
(As a disclaimer, I currently do not use or design FPGAs. I have,
however, had a good bit of experience using the various tools)
From what I have read and heard about several major FPGA companies,
this is not the case. A significant portion of their income DOES come
from the software they sell to make the chips easier to use. This
software is also very different from that used simply to test the chips.
>make their software available cheaply (or even on an Anon FTP server, like
>Intel) many people who would never consider buying a highly-priced package,
>they might just sell more chips.
Being able to get your product to market faster than the other guy is
very often more important than the base cost of chips you use. Thus,
having software which can shorten the development time does have some
value. Even "expensive" software appears cheap when amortized over 100,
1000, or even 10,000 units of your product.
>Perhaps I've spent too much time hacking Unix, and I've come to expect that
>you can get virtually any item of software (operating systems, compilers,
>databases etc) in source code form for free. However, as far as I'm
>concerned, the bottom line is this:
>The manufacturer is making a product to sell.
>I would like to buy and use that product, for which I need technical
>information and/or development software.
>I am quite prepared to pay for the information or software, provided the
>cost doesn't exceed that of a couple of the chips.
>To me, comprehensive technical documentation is not far removed from
>advertising, and I don't expect to pay much more than the cost of production.
From a hobbyist standpoint, I too would like to see cheap software
so that I can build all kinds of circuits quickly without a large
stockpile of TTL next to me with a pound of solder. However, you
have to remember that we, as hobbyists (AKA low- or almost zero-volume
purchasers of a product) are very far from the minds of the chip
companies when they write software. The business users and their
interests (development time, ease of use, software quality, etc.)
must come first since they're the ones that pays the bills.
---------------------------------------------------------------------
Robert J. Landers landers@hc.ti.com
Texas Instruments, Inc. Dallas, Tx
Opinions expressed above are mine and not those of Texas Instruments.
---------------------------------------------------------------------
Article: 67In article <Cu2psC.DwE@liverpool.ac.uk>, rsb@liverpool.ac.uk (Roger Brooks) writes... >Finally a point to ponder. When I was a student about 20 years ago, TTL >chips were pretty well state of the art. You could buy them quite easily, >you could get hold of the manufacturers' data books, and armed with not >much more than a home-made logic-probe and a large amount of persistence >and low cunning, you could build things like digital clocks. This was the >time when a commercially-built ``digital clock'' generally contained an >electric motor and a lot of gears which turned drums with numbers printed >on them. When you had built your TTL alarm clock or whatever you almost >certainly felt a great sense of achievment, as you had got something which >it was difficult (if not impossible) to buy at that time. When I started in electronics (a long, long time ago!), people were still designing with valves (admitedly, most commercial stuff had moved to solid state, but homebrewing with valves was common). Now, what did you need to design/build valve circuits -Multimeter (VOM/AVO - call it what you will) -Metal bashing tools (or woodbashing) -Soldering iron -Possibly a 'scope -Possibly a PSU, if you couldn't rip a suitable transfomer from an old radio. Transistors were even easier - no metalbashing, lower voltages. TTL, well, you needed a solder sucker. And a logic probe (although I debugged my first microprocessor project using an LED and a 470 Ohm resistor in an old pen case :-)). You didn't need a logic analyser. You could experiment at home.I did. I've built some wonderfully complex TTL circuits. And I repair TTL-based computers... Now look at FPGAs. I need a powerful PC (no matter that I have several obscure computers that are as fast as a 386, and probably a lot nicer to use. No matter that I don't care if my placings/compilation takes all night). I need a lot of money for a software package that I can't fix if it doesn't work (No source code). I need to _buy_ a programmer that comes without schematics/timing info. I can't experiment at home! > >Inevitably, the increasing use of custom chips and PLDs will lead to a >reduction in the range of MSI and SSI devices, and possibly a significant It already has. A lot of TTL devices I need to keep some of my computers running are not available easily any more. I've had to program GALs to replace them, and hope the timing is OK... >increase in their cost. If PLD development tools are priced out of the >reach of the keen amateur, digital electronics as a hobby is on its way to >dying out. Why should the electronics industry worry about this? Well I >suspect very few people wake up one morning and decide to register for a >degree in electronics. Most of them become electronic engineers because of >a long standing interest in electronics. The kind of person who will become a I certainly did. If I hadn't grown up playing with valves, transistors, TTL chips, etc, I wouldn't be reading this group now. I wouldn't be designing today. >highly talented engineer (once he or she has got past the elementary stage >of building amplifiers that oscillate and oscillators that don't) will want >to build something difficult and state-of-the-art. Glancing through Agreed.... >Tracey Kidder's ``The Soul of a New Machine'' the other night provided >ample confirmation of this, including one engineer who had built an FPU >while in college. If PLD manufacturers continue to price their development >tools out of the reach of the individual hobbyist, it may be an effective >way of persuading a lot of talented people that their future lies in some >field other than digital electronics. > >I would like to echo the earlier call for low-cost unsupported, no-frills >software. I've heard several bogus arguements as to why the programming algorithms/bit allocations are not published 1) You couldn't hope to understand them, and you couldn't possibly write tyour own software. Well, I wonder how many home constructers in the early 70's understood Wallace tree networks, parity trees, propagation delays, lookahead carry, etc. Yet they were all in the TTL handbook. I learnt a lot from that manual. Maybe if the FPGA stuff was explained I could understand that too. I understood some of the internals of operating systems by hacking about in Minix. I'm sure I could program a FPGA if it was explained 2) You can damage the chips by misprogramming them So? I can damage the chip by applying 240v to the Vcc pin. Or applying static. Or plugging it in backwards. If you like, have a secret flag inside the chip. Don't explain how to program it, and make it a complex request/response algorithm. Make the flag have no effect on the device, except that it is readable when the security fuse is blown. Now, make the 'approved' programmer set said flag. So, if a chip is sent back because it's faulty, if the flag is not set or readable, the chip was not programmed in an approvbed programmer. I'd buy chips under those conditions, if I could make my own programmer. 3) We couldn't support you I'm not asking for support. I accept that if I try and program the device on my own, that's my affair. Just tell me how to do it. Anyone want to continue the list? > > >Roger > >-- > >------------------------------------------------------------------------------ >Roger Brooks, Systems Programmer, Computing Services Dept, | rsb@liv.ac.uk >The University of Liverpool, PO Box 147, Liverpool L69 3BX | +44 51 794 4441 >------------------------------------------------------------------------------ -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned.Article: 68
In article <Cu87E6.H02@jabba.ess.harris.com>, thomae@trantor.harris-atd.com writes... >Xilinx has had the lion's share of the attention so far as SRAM based fpgas go. >Does anyone know of a company that manufactures SRAM based fpgas that also >has a cooperative enough attitude that they'll release sufficient technical >data to make it possible to write freely available tools like place and route >software? It's a great pity it is secret (and yes, I couldn't find it out either), because given a completely documented SRAM FPGA, you could, at least in theory, make a circuit that reconfigured itself. Having once written self-modifying _microcode_ in binary, I'd like to experiment with that sort of thing. But I can't, because I've not found a _documented_ chip. A daft idea.... The architecture of FPGAs is well known/documented. How impossible would it be to design one, and have it built in silicon. Just an Small-ish SRAM one. I'm sure a _lot_ of netters would buy them... > >-- >----------------------------------------------------------- >Douglas Thomae thomae@trantor.harris-atd.com (407) 729-7253 >Advanced Technology Dept., Harris Corp. -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned.Article: 69
In article <Cu87E6.H02@jabba.ess.harris.com> thomae@trantor.harris-atd.com writes: >I've thought of trying to reverse engineer the format using the Xilinx tools >and got far enough along to realize what a big job it is (too much for the >grad student I was at the time to fit into his schedule). In addition, I'm >uncertain about the legalities involved (is it possible to copyright or >patent a file format?). I doubt it. More to the point, however, I bet that the license agreement for the Xilinx tools contains a clause in which you swear not to attempt to reverse-engineer them. That's legally binding regardless. -- "We must choose: the stars or the dust.| Henry Spencer @ U of Toronto Zoology Which shall it be?" -H.G.Wells | henry@zoo.toronto.edu utzoo!henryArticle: 70
In article <8AUG199421054121@siva.bris.ac.uk>, ard@siva.bris.ac.uk (PDP11 Hacker .....) writes: > In article <Cu2psC.DwE@liverpool.ac.uk>, rsb@liverpool.ac.uk (Roger Brooks) writes... >>Why should the electronics industry worry >>about this? Well I suspect very few people wake up one morning and >>decide to register for a degree in electronics. Most of them become >>electronic engineers because of a long standing interest in >>electronics. > Agreed.... Count me in, too. The problem seems to be convincing the big semiconductor firms of this. Does anyone have any ideas? > I've heard several bogus arguements as to why the programming > algorithms/bit allocations are not published > 1) You couldn't hope to understand them, and you couldn't possibly > write tyour own software. > 2) You can damage the chips by misprogramming them I think these both lead into (3), from their point of view. I.e., you can't possibly figure out how to use the part correctly, so you'll damage it, and then call us to ask for support. > 3) We couldn't support you > I'm not asking for support. I accept that if I try and program the > device on my own, that's my affair. Just tell me how to do it. Agreed: it makes sense that companies don't want to provide technical support to someone who's building a project in their basement -- this clearly isn't going to make them any (short-term) money. But all we're asking for is databooks. I've said this before: I'll be happy to agree (in writing and signed if they want) not to request any technical assistance beyond data sheets on non-commercial (hobby) projects. Can someone who has worked / does work at one of the big semiconductor firms tell us if this is really a problem? Do your tech support people get a lot of calls from hobbyists asking stupid questions? Unless I hear otherwise, I tend to think that hobbyists are more likely to try to figure things out themselves before they call up the manufacturer. That's how you learn. Anyone can solder kits together; electronics design takes skill. And then they'll ask their friends, profs, the net, whatever, > Anyone want to continue the list? Maybe we should call up all of the big companies and ask them. Trying to guess their reasons doesn't make a whole lot of sense. - Derek -- Derek Noonburg derekn@vw.ece.cmu.edu Electrical & Computer Engineering Dept., Carnegie Mellon UniversityArticle: 71
Can someone using NEOCAD tools for synthesizing into ALTERA FPGA's share their experience with me. I am describing my design in VHDL. I have evaluated Exemplar tools and found them to be far superior to Altera's VHDL tools. Thanks, Sundar GopalanArticle: 72
>I've heard several bogus arguements as to why the programming algorithms/bit >allocations are not published > [ . . . ] >Anyone want to continue the list? 4) Security for proprietary designs. Without knowing what the bits mean, one cannot reverse engineer a design by watching the bit stream being leaded into the chip. Many FPGA vendors, and presumably some of their biggest customers, see this as a feature to be protected. The Xilinx 1994 Data Book on page 9-15 in an article called "Design Security" says: "... its is virtually impossible to use the bitstream to understand the design or make modifications to it. Xilinx keeps the interpretation of the bitstream a closely guarded secret." So, I doubt you will have any luck in persuading them to divulge these secrets.Article: 73
My name is Ken Reiter; I am a Emulation Specialist with Quickturn Design Systems, based in Dallas, Texas. I am sorry that any requested information from our Mt. View office was not sent to you. THIS IS A OPEN OFFER - ANYONE WHO WOULD LIKE INFORMATION ON QUICKTURN's PRODUCTS MAY CALL OR EMAIL ME FOR THE INFORMATION. Ken Reiter Emulation Specialist Quickturn Design Systems 214-516-3831Article: 74
Will Rose (cwr@crash.cts.com) wrote: : I bought a copy of a cut-down version of Xact 5.0 (the current : Xilinx software) from Xilinx for $20, but with no simulator it's I happen to be using an non-xilinx simulator anyway..... : not in fact much use. The full-house version costs around $1000, Hmmm. Our version cost around $3000. Could it be that there are large differences between countries? -- * As a protest against the recent bunch proposed anti-cryptography * * laws, this message has been doubly encrypted using the rot13 algorithm. * EMail: wolff@dutecai.et.tudelft.nl ** Tel +31-15-783643 or +31-15-142371
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