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 <4e0f88$b25@agate.berkeley.edu>, Steve Pope <spp@bob.EECS.Berkeley.EDU> wrote: >Brian Childs <brian@vizef.demon.co.uk> writes: > >> I also agree with this trend. In fact it is already here... You only >> have to look at the companies who used to (and probably still do) >> provide custom design services, who now publish/market an extensive >> range of 'off the shelf cores'. > >This is because whenever a design shop designs a chip for one >customer, its elements then become potential "off the shelf cores" for >the next customer. Problem is, the actual level of circuit >re-use is always lower than one hopes. Rule of thumb -- if you >can get by with less than half of a design being newly-designed >circuitry, you're doing really well. In my experience, the amount of curcuit re-use increases tremendously when you are allowed to make (small) modifications to a previous design - and I don't mean setting a few parameters differently here... We do have large groups of students working and learning here using our own tools, and they are copying and pasting all over the place. Everything they made over the last couple of years is placed in a central depository, we do not allow anything in there which is not thoroughly documented (both on paper and within the designs themselves). Not only complete designs are open for re-use, but also any sub-part of a design can be copied in separation. > >If the design shop is accumulating large numbers of "off the shelf >cores" it's a good bet they are desinging these things anew for each >customer and that is why they have so many of them. I think design shops should worry more about building cores which are robust enough to be modified by their customers than to create 'new' cores on request (which stop working as soon as a slight modification has been made). > >> What appears to be missing is any good >> design tools to assist designers (or do you know different). > >We've been saying this for the last 15 years. :) Going to whisper mode: take a look at our tools... Check out http://www.eb.ele.tue.nl/proj/idassfly.html ...fully interactive designing and simulating within a graphical environment - capable of handling very complex designs, VHDL output and automatically generated test environments available (as of today :-). If you want to play around with it, drop me an e-mail... Ending whisper mode, sorry for the advertisement, just couldn't resist :-( > >Steve Ad Verschueren --(dr.ir.) Ad (A.C.) Verschueren-----------------------VERSCHUE@EB.ELE.TUE.NL-- Eindhoven University of Technology Digital Information Processing Systems Smail: Room EH 10.26 ---- P.O. Box 513 ---- 5600 MB Eindhoven, Netherlands Voice: +31-40-2473404 FAX: +31-40-2448375 [corner for rent, apply within] -- --(dr.ir.) Ad (A.C.) Verschueren-----------------------VERSCHUE@EB.ELE.TUE.NL-- Eindhoven University of Technology Digital Information Processing Systems Smail: Room EH 10.26 ---- P.O. Box 513 ---- 5600 MB Eindhoven, Netherlands Voice: +31-40-2473404 FAX: +31-40-2448375 [corner for rent, apply within]Article: 2701
verschue@eb.ele.tue.nl (Ad Verschueren) replise to my post, >>This is because whenever a design shop designs a chip for one >>customer, its elements then become potential "off the shelf cores" for >>the next customer. Problem is, the actual level of circuit >>re-use is always lower than one hopes. Rule of thumb -- if you >>can get by with less than half of a design being newly-designed >>circuitry, you're doing really well. | In my experience, the amount of curcuit re-use increases | tremendously when you are allowed to make (small) modifications | to a previous design - and I don't mean setting a few parameters | differently here... We do have large groups of students working | and learning here using our own tools, and they are copying and | pasting all over the place. Everything they made over the last | couple of years is placed in a central depository, we do not | allow anything in there which is not thoroughly documented (both | on paper and within the designs themselves). Not only complete | designs are open for re-use, but also any sub-part of a design | can be copied in separation. I agree that you are describing techniques that serve to increase re-use. But I'll stand by my estimate that anything better than 50% re-use -- for REQUIREMENTS DRIVEN projects -- is really pretty good, even with the techniques you mention. Of course, for RESOURCE DRIVEN projects, you will get more re-use more readily. (e.g., "What cores do I already have, and what can I design with them" -- i.e. a typical university situation.) SteveArticle: 2702
In article <4e7lbm$idl@news.alcatel.ch>, Peter Siegrist <sigi> wrote: > Ja es ist moeglich > Ich steuere mit meine 4010 exteren SRAM 25ns, DUAL_Port_RAM 25ns > und die Interen RAM's ca.20ns > Ja, es ist jetzt sogar noch viel besser geworden: The new XC4000E family has synchronous and dual-port RAM. You can treat the RAM block as if it were a register. Address, Data, and Write Strobe=Write Enable only have to meet the set-up time before the global clock edge. No more need for careful timing to make sure that WS starts and ends during valid address times. Try it, you'll like it. Peter Alfke, Xilinx Applications, San Jose, CAArticle: 2703
Gavin Melville (gavin@cypher.co.nz) wrote: : Hi All, : I am using the windows based XACT (step) tools, and have found them to : be a little "flaky", with occasional lockups and crashes -- in : particular the Design Editor (V5.2.0). This version has run fine : from DOS, but the need for simulation has forced me to use the Windows : tools. One particular problem -- XDE doesn't always seem to generate : the same bitstream each time DebugLoad is run. [etc deleted] I have beenusing XACT 6.0 since June 95. I have installed them on more than ten machine from a 486-33 with 20Mb RAM to Pntium-133 with 64 MB. I have seen a net productivity gain of at least 2x from start to finish. Yes, sometimes the tool will crash but in over 7 months of usage not any more than any other windows applications. I have found that more crashes is an indication (most times) of an unreliable windows installation or flaky hardware, both of which have nothing to do with XACT. You definitely get a bit more performance by using WFW. Email me if you need help on XACT 6.0 Alan Arnaud (arnaud@ecla.com) ECLA Inc. -Networking ASICS and FPGAs designs- 1-800-928-1236 Newton, MAArticle: 2704
We are offering a gate-level description of the popular 8051-type microcontroller suitable for use with most ASIC manufacturers (FPGA, gate array, or standard-cell). Licenses are available starting at US$2995 for a single ASIC type at a single foundry. More detalis can be obtained by anonymous ftp to ftp.netcom.com in the directory /ftp/pub/ic/icdc in the file nld.txt or via the Web at ftp://ftp.netcom.com/pub/ic/icdc/nld.txt or reply to this post. __________________________________________________________________________ _ ____ __ ____ ____ | | | __| / / | _ \ | __| Integrated Circuit Design Concepts | | | | / / | | | | | | 12502 Carmel Way, Santa Ana CA 92705 | | | |__ / / | |_| | | |__ Voice (714) 633-0455 Fax (714) 838-7705 |_| |____| /_/ |____/ |____| _________________________________________________________________________ -- __________________________________________________________________________ _ ____ __ ____ ____ | | | __| / / | _ \ | __| Integrated Circuit Design Concepts | | | | / / | | | | | | 12502 Carmel Way, Santa Ana CA 92705 | | | |__ / / | |_| | | |__ Voice (714) 633-0455 Fax (714) 838-7705 |_| |____| /_/ |____/ |____| _________________________________________________________________________Article: 2705
Next week at the HP Design SuperCon '96 I'll be running an ESDA Shootout on Tuesday afternoon. (Our goal is to determine whether the ESDA tools like those sold by i-Logix, Summit, and Speed can do better or worst than everyday engineers designing ASIC's using plain old "vi" or EMACS.) Given 90 minutes, ASIC designers will be asked to hand code a small state machine and then to synthesize it to gates. The ESDA Vendors will be sweating it out creating the *same* design using *their own* ESDA tools! The top hand-coding ASIC designers who produce the fastest running gate-level designs will win instant fame (in the write-up of the contest) with the best winning an HP color laser printer! Since we don't have an infinite number of workstations available, if you're interested in being a part of this contest *please* e-mail me *TODAY* at "jcooley@world.std.com" so we can get an estimated head count. NAME:_________________________ Phone Number:____________________ e-mail address:___________________________________________________ Prefered HDL (Verilog or VHDL):___________________________________ Oh, don't forget to come to the panel discussion the next day (Wednesday, Jan. 31st) to see the ESDA vendors either gloat on their victories or squirm trying to explain why their tools couldn't cut it. Or, if things go awry, you could find the contest judge (me) sweating it out trying to explain why things got screwed up! :^) - John Cooley Part Time EDA Consumer Advocate Full Time ASIC, FPGA & EDA Design Consultant =========================================================================== Trapped trying to figure out a Synopsys bug? Want to hear how 3881 other users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)! !!! "It's not a BUG, jcooley@world.std.com /o o\ / it's a FEATURE!" (508) 429-4357 ( > ) \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys, _] [_ Verilog, VHDL and numerous Design Methodologies. Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222 Legal Disclaimer: "As always, anything said here is only opinion."Article: 2706
Philipp, I have realized a design in XC4013-4, running at 20MHz, that reads and writes a SRAM at full speed. It is my experience, that there are no problems. Use the registered Pads (INFF, OUTFF) to get well defined timings. Even registerd I/O-Ports can be built. If you need access at full speed, you need a WE-Signal, that is the gated system clock. Be carefully generating this signal. Additionally I realized an arbiter for the RAM access, so that several blocks within the FPGA can access the SRAM. Bye, Peter. --------------------------------------------------------- Peter Wurbs (MAZ Hamburg GmbH, Dep. Broadband Communication) Phone: ++40-76629 1771 Fax: ++40-76629 199 e-Mail: pwu@maz-hh.de ---------------------------------------------------------Article: 2707
In <4e68e6$9c1@mailman.xilinx> "Steve Knapp (Xilinx, Inc.)" <stevek> writes: > >The concept seems feasible. A few questions though: > >1. How much RAM is required? General the XC4000E RAM is good for designs > requiring less than 64 words of memory. Increasing the word width does not > significantly increase the amount memory required. > > Some example sizes: A 32-deep memory of 16-bit words consumes 32 XC4000E > logic blocks. A 64-deep memory of 16-bit words consumes 80 logic blocks > (64 for the RAM, and 16 for bank select and output multiplexing). Quite true, but sometimes you can take advantage of the 4000(E)'s abundant 3state drivers to have deep (multi-bank) memories w/o having to waste CLB gates multiplexing bank data outputs. Assuming you are already using horizontal long lines for an on-chip data bus of some kind, multiplexing bank outputs is as simple as decoding more significant address lines into bank enable signals which enable tbufs to drive bank data outputs onto the shared data bus. Fortunately, the tbuf inputs are immediately adjacent to the SRAM/ROM CLBs so trivial routing resources are consumed. Floorplan-wise, the data bus runs horizontally, each SRAM/ROM bank is a column of CLBs and TBUFs, with addresses, WE, and bank select longlines running vertically. For instance, my 4010-based 32-bit RISC has several banks of 16 words x 32-bits of on-chip boot ROM. Address bits A[7:6] control bank output enables, A[5:2] specify the word address across all banks, and A[1:0] is decoded with the processor's data-width specifier (byte, halfword, word) to derive byte enables. The bank output enables and byte enables are and'd together and each result drives 8 "data out" tbufs for some byte in some bank. Jan Gray Redmond, WAArticle: 2708
I am looking for a design library for a software UART for the Xilinx xc4000 series. I would really like to have something that would be very similar to the Motorola 68681 Duart. Does anyone know of a company that may be producing this kind of library. We would not prefer to recreate the wheel if at all possible. Thanks in advance. -- Mike Saunders Datron World CommunicationsArticle: 2709
I am requesting any and all feedback regarding in-house training of VHDL/Verilog. This could be tutorials, seminars, video tapes, etc... I am looking for prices, quality assessments, contacts, etc... Also, any comments from individuals who have received this type of training from a professional training service would be appreciated. -- \\\\\\\\\ \\\\\\\ \\\\\\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ \\ \\ \\ \\ \\ ^ Timothy D. Bouvia ^ \\ \\ \\ \\\\\\ ^ HRB Systems, Inc., Dept. 112 ^ \\ \\ \\ \\ \\ ^ State College, Pa. 16804-0060 ^ \\ \\\\\\\\ \\\\\\\\ ^ Internet: tdb@icf.hrb.com ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Article: 2710
In article <4e8ed3$boc@agate.berkeley.edu>, Steve Pope <spp@bob.EECS.Berkeley.EDU> writes >verschue@eb.ele.tue.nl (Ad Verschueren) replise to my post, > >>>This is because whenever a design shop designs a chip for one >>>customer, its elements then become potential "off the shelf cores" for >>>the next customer. Problem is, the actual level of circuit >>>re-use is always lower than one hopes. Rule of thumb -- if you >>>can get by with less than half of a design being newly-designed >>>circuitry, you're doing really well. > >| In my experience, the amount of curcuit re-use increases >| tremendously when you are allowed to make (small) modifications >| to a previous design - and I don't mean setting a few parameters >| differently here... We do have large groups of students working >| and learning here using our own tools, and they are copying and >| pasting all over the place. Everything they made over the last >| couple of years is placed in a central depository, we do not >| allow anything in there which is not thoroughly documented (both >| on paper and within the designs themselves). Not only complete >| designs are open for re-use, but also any sub-part of a design >| can be copied in separation. > >I agree that you are describing techniques that serve to increase >re-use. But I'll stand by my estimate that anything better than >50% re-use -- for REQUIREMENTS DRIVEN projects -- is really >pretty good, even with the techniques you mention. > >Of course, for RESOURCE DRIVEN projects, you will get more re-use >more readily. (e.g., "What cores do I already have, and what >can I design with them" -- i.e. a typical university situation.) > >Steve I seen this 50% trend too. The only time I've seen significant re-use is on designs which are evolutionary rather than revolutionary. In fact most ASIC's tend to be evolutionary i.e. taking an existing design on to new heights. Where re-use tends to fall off is when the next design iteration is carried out by a new team and then a touch of NIH sets in. Not 'Not Invented Here' *but* 'No Information Here'. If the design is not documented adiquately and the designer cannot quickly understand how a module is implemented there is the tendency to start again. This is not new, software engineering has had this problem for decades. The 'mistake' I feel is in the original promotion of HDL's, by the EDA companies, as enabling technology for design re-use. This is like saying C++ enables design re-use because it is different to C. It is good design practises that are needed which will create an environment that fosters design re-use. Re-use of poorly document design modules leaves a real risk of misunderstanding and subsiquent delays to schedules. This is something seasoned engineers are all to aware of and tend to avoid the re-use option where the risk is tangable. -- Steven BirdArticle: 2711
In <1996Jan26.132727.24274@hrbicf> tdb@icf.hrb.com (T. D. Bouvia) writes: > > >I am requesting any and all feedback regarding in-house training of >VHDL/Verilog. This could be tutorials, seminars, video tapes, etc... > >I am looking for prices, quality assessments, contacts, etc... > >Also, any comments from individuals who have received this type of training >from a professional training service would be appreciated. > You can get excellent training for VHDL through IKOS systems. They have relationships with consulting companies that spec- ialize in VHDL training. IKOS themselves gives excellent simulation/co-simulation trainging also. One of the consul- ting services companies they deal with is "Top Down Design". A contact at IKOS is their sales person in your area. His name is Mike Kochanik. (201) 445-7001 ext 202. His email is "mikek@ikos.com" I've been through this VHDL training program and it's very good. FGArticle: 2712
In <DLKnL8.LJ9@world.std.com> jcooley@world.std.com (John Cooley) writes: > >Tony Goodloe <tgoodloe@adtran.com> wrote: >>Verilog vs. VHDL - IT DOESN'T MATTER! People have shipped products >>and made money using each. Learn one. Don't fret about the decision. >>The hard part is understanding what HDLs are all about in general. >>Once you learn one, the other will come. > >Sorry, Tony, but I have to disagree with you on this one here. Unlike Europe >or in Japan, U.S. engineers are basically hired by the buzzwords they have >on their resume *and* how well the engineers know them. Most U.S. companies >don't like to train if they can get a person with the right buzzwords in the >first place. In light of the last 10 years, most U.S. workers know they're >disposable at any moment -- so it pays to keep your career such that the >right buzzwords are on your resume at all times. > Hogwash! People are hired on ability in this industry. And what matters is not which HDL you know but if you understand how to implement the entire methodology/process to get a chip from specification - through synthesis - through verification - and through signoff. If you can do this you will be valu- able to any and all companies that design chips. It is im- portant to understand differences between VHDL and Verilog, but that's not what will keep you employed in this industry... FGArticle: 2713
jcooley@world.std.com (John Cooley) writes: >Sorry, Tony, but I have to disagree with you on this one here. Unlike >Europe or in Japan, U.S. engineers are basically hired by the >buzzwords they have on their resume *and* how well the engineers >know them. Most U.S. companies don't like to train if they can >get a person with the right buzzwords in the first place. In light >of the last 10 years, most U.S. workers know they're disposable at >any moment -- so it pays to keep your career such that the right >buzzwords are on your resume at all times. Frank Guerino <guerino1@ix.netcom.com> wrote: >Hogwash! People are hired on ability in this industry. And >what matters is not which HDL you know but if you understand >how to implement the entire methodology/process to get a chip >from specification - through synthesis - through verification >- and through signoff. If you can do this you will be valu- >able to any and all companies that design chips. It is im- >portant to understand differences between VHDL and Verilog, >but that's not what will keep you employed in this industry... > >FG Frank, I think you're missing my point that this "ability" usually is measured by how well one knows buzzwords like "Synopsys", "MOTIVE", "DFT", "DSP", "Verilog" -- you've never had a headhunter call you up asking if you know buzzword "XYZ"? You've never known engineers who were hot career-wise because they knew these buzzwords or others who weren't doing so well because they didn't have the right buzzwords? (I've known plenty of DoD engineers who knew chip design but who have had bad times getting a new job because it wasn't with the commercial EDA tools the rest of industry uses.) If you're one of the three Americans working in a company that will guarentee your job as long as the company lives, great. Unfortunetly, most the rest of us remaining 250 million Americans *have* to constantly keep our *marketable* skills contuniously up to date *because* we don't know what the future brings. That is, if the company needs you to develope firmware using their own funky proprietary software versus using industry wide tools to design a new ASIC, it would be damn wise to take the industry wide tools job! When I was at Data General I used to know experts in their propietary OS called "AOS" -- when they downsized the UNIX jocks got jobs & career advances in a heartbeat. The "AOS" wizards (who had exact same skills in the wrong brand name ("AOS" versus "UNIX")) had one hell of a time finding work! Also, Frank, don't confuse the fact that right now engineers are hired pretty much because they're what's available right now due to the current 6 month shortage of them. Once the glut comes back, it'll be disposable employee as usual. - John Cooley Part Time EDA Consumer Advocate Full Time ASIC, FPGA & EDA Design Consultant =========================================================================== Trapped trying to figure out a Synopsys bug? Want to hear how 3713 other users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)! !!! "It's not a BUG, jcooley@world.std.com /o o\ / it's a FEATURE!" (508) 429-4357 ( > ) \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys, _] [_ Verilog, VHDL and numerous Design Methodologies. Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222 Legal Disclaimer: "As always, anything said here is only opinion."Article: 2714
I'd really, really like to get rid of the NOR gate glue logic and replace it with some species of GAL. I have PLDasm and it's manual and can now create the JDEC files. Unfortunately, my PROM programmer is just that... PROMs only. Do I need to get another programmer or can one home brew for a specific chip? thanks! mark -- mark stephens "In constraint, NASA GSFC Code 521 is freedom" Greenbelt, MD (301) 286-4269 mark.stephens@gsfc.nasa.govArticle: 2715
kurt@emphasys.de wrote: > >Hi, >has anyone expirience with AT&T ORCA FPGAs ? >For some designs we think about switching from Xilinx to ORCA. >Thanks in advance for any information and comparison of the tools. >Kurt. I've been using ORCA for about a year now, and have rarely been tempted to go back to Xilinx. The parts seem to be better optimized for the types of circuits that I'm doing. They especially excel at things that require: 1) Wide internal tri-state busses. The ORCA has 8 TBUFs per PFU which can drive horizontally or vertically. The 4000 has 2 per CLB on horizontal lines only. (This is equivalent of 4 per PFU assuming that 1 PFU is roughly equivalent to 2 CLB.) 2) Large arithmetic functions. Each PFU can be a 4-bit adder/subtractor. 3) Multi-way multiplexers. Each PFU has a multiplexed data input to its flip-flops. This allows, for example, a 4-bit loadable up/down counter to be implemented in only a single PFU. Also, it allows a 4-bit wide 3-to-1 multiplexer to be implemented in a single PFU. I use this function a lot. Unfortunately, the sofware doesn't supprt this very well. The only way to use it is to make hard macros. 4) Lots of I/O pins. Software: The ORCA software leaves a bit to be desired. The user interface is not very well designed (compared to Xilinx). There is essentially no control over mapping and very little control over placement and routing. Specifying timing constraints requires a lot of patience. On the PC, only one of the tools can be used at any time - you can't run a place'n'route in the background while using the other tools. My guess is that a good man-year of effort could clean up most of the problems and make this a really useful tool. Cost: When I checked about 9 months ago, ORCA parts were about 1/2 the price of equivalent Xilinx parts. This has probably changed significantly. Recommendation: It seems like a toss up to me. ORCA is cheap (but dirty), and can do some things that Xilinx simply can't do with any sized chip. Xilinx has better software and support and provides a broader line of chips. If you're buying a first system, I would get Xilinx unless you need a special capability that ORCA has.Article: 2716
In article <4ee3lk$et@cloner2.ix.netcom.com>, Frank Guerino <guerino1@ix.netcom.com> wrote: >Hogwash! People are hired on ability in this industry. [...] Yes, *but* you need to have the right buzzwords on your resume to get it passed the (automated?) pre-screening process that happens before anyone from the hiring department gets to see it. Mark -- definately not speaking for Intel.Article: 2717
in <mark.stephens-2901961009190001@mstephens.gsfc.nasa.gov>, Mark Stephens wrote: : I'd really, really like to get rid of the NOR gate glue logic and replace : it with some species of GAL. I have PLDasm and it's manual and can now : create the JDEC files. Unfortunately, my PROM programmer is just that... : PROMs only. : Do I need to get another programmer or can one home brew for a specific chip? So you want to build a PLD programmer: a FAQ File [Last Revised: January 29, 1996] (The following is aimed at the level of the basement hacker, restricted to lower complexity parts. Which is what I've found in the surplus market.) So you want to build a logic device programmer. Here's a list of articles and databooks that I've scraped together. Grouped by devices supported and in order of usefulness (IMHO). Just remember that if you build your own programmer, factor in some money for test data (that is, destroyed parts). Unless you're using cheap parts, the $500 to $700 you tried to avoid spending for an inexpensive programmer could add up sooner than you expected. First, be aware that the manufacturers don't feel it's in their interest to give you enough information to build one. There's a couple of reasons. Some them make money by selling programmers and software. Some of them don't want to spend a lot of money trying to figure out why you (and thousands others like you) can't get parts to program (or worse, stay programmed) using your homemade programmer. So, starting around 1985, most manufacturers have removed this information from their databooks. Expect most CMOS parts to have proprietary algorithms. Also expect as parts are redesigned to be faster, the old programming algorithms may be obselete, or have certain parameters in them shift. But if you are convincing, some of the manufacturers will give you the information on a nondisclosure basis. (I've heard National and TI are pretty nice. And Cypress doesn't even require a nondisclosure agreement. But Lattice and AMD are downright rude. Unfortunatly, National is reported to be getting out of this business.) And there is a new trend in industry that will help the hobbyist. Manufacturers would like to control their inventory, but the way older parts are programmed adds extra (possibly) expensive steps to the process of making a circuit board: procuring and inventorying the unprogrammed parts, programming them, reinventorying the programmed parts (and insuring they are programmed and marked correctly), making sure they are available to be inserted in the circuit board, and placed the right location ... And after all of that, the board is tested in Automatic Test Equipment. This automatic test equipment has the same sort of electronics that a device programmer has (and have been used for this at many companies). So why not design parts that can easily (without destroying connected circuitry) programmed during the final test stage and skip many of the steps mentioned in the previous paragraph. In order to do this, the semiconductor companies have to make the parts easy to program, and release the programming algorithms. Intel and Lattice with their Flex and ispLSI families are doing this. Altera has taken over Intel's PLD operation as of October '94. 1. GALs (EEPROM based), from Lattice, National and SGS-Thomson "Build This PLD Programmer" by Robert G. Brown Electronics Now (magazine), May 1994 This is a simple programmer limited to the 16v8 and 20v8 parts. It consists of two circuit cards, one a general purpose parallel port for the IBM PC and a programmer card with the drivers, ZIF socket, and voltage regulators. (Very similar to the Elektor project.) Various kits and software available from R.G. Brown 30 Wicks Road E. Northport, NY 17731 "Project: GAL programmer" by Manfred Nosswitz. Elektor Electronics (magazine), May 1992 This is a simple (5 IC's, 7 transistors, 2 voltage reg.) board driven by a program (in this case for an IBM PC or clone) using the computer's printer port. It supports the 16v8, 20v8 original and A versions. "Project: GAL Programmer Upgrade" by M. Nosswitz Elektor Electronics, June 1993 An add-on board with a D/A converter to allow a variable programming voltage, and a new software driver. Now programs B version GALS, 22V10's, 20RA10's, and the GAL6001 PLA. The software and PC boards are available through the Elektor publishers/franchises in various countries. In the US this is Old Colony Sound Lab (the publishers of Audio Amateur, and the former publisher of the US edition of Elektor Electronics). Old Colony Sound Lab P.O. Box 243 Peterborough, NH 03458 (603) 924-6371 or -6526 Fax (603) 924-9467 In the UK Elektor Electronics (Publishing) P. O. Box 1414 Dorchester DT2 8YH England The item number for the software is 1701, the US price as of June 1993 is $22.30, the UK price 11.15 pounds. The software upgrade is item 1881, $21.50 or 10.75 pounds. The PC board is item 920030, US $22.30, UK 11.15 pounds. The PC board for the upgrade is 930060, $9.50 or 4.75 pounds. Back issues may still be available from Old Colony, otherwise the address is Worldwide Subcription Service, Ltd. Unit 4, Gibbs Reed Farm Pashley Road, Ticehurst TN5 7HE England "Generic Array Logic (GAL)" D. Gembris Elektor Electronics, April 1992 A description of the architechture of a GAL, along with the programming algorithms. Unfortunatly this describes the nonvolatile memory layout for the original version parts, and the A version parts would not work if this information were used. Some other information is left out, including describing the nonvolatile memory register that contains the part ID code and manufacturer. (This article is useful if you want to disassemble the software from the previous reference, but incomplete otherwise. Not really needed if you want to build and use the project as is.) 2. Cypress and Samsung (UVEPROM based) Contrary to the trend. Cypress Semiconductor published the algorithms for the simpler PLD chips they produced. They have since discontinued this, and you have to request them, but no special agreement is required. As of the 1990 databook, they included the algorithms for their 16L8, 16R8, 16R6, 16R4, 20G10 (like a smaller 22v10), and their 22v10 devices. Judging from the algorithms in their 1988 databook, Samsung is a second source for Cypress. Their CPL 20 family is the same as the Cypress devices. In addition, they have 24 pin devices with the same technology that implement the 20L10, 20L8, 20R8, 20R6, and 20R4 devices. "EPLD programmer design" John Cromie Electronics & Wireless World, February 1989 An article describing a single chip microprocessor driven programmer (using a Hitachi 63701) that programs the devices. "Contact the author for software.", a common trend in this publication's "projects". 3. PEEL18CV8 (EEPROM), from International CMOS Technology, Gould AMI "Create Your Own IC's", Bill Green Popular Electronics, January 1990 A single board Z80 based programmer for the PEEL18CV8 using keyboard entry. No algorithm description. PLD and EPROM for z80 program needed to duplicate. (Listed price was cheap, about $80 in 1990.) Later versions were produced that had an interface to download from a computer, rather than keypad only entry. 4. CPLDs from Intel/Altera and Lattice Databooks from Lattice, "pLSI and ispLSI Data Book and Handbook" and Intel, "Programmable Logic" have the interface and download specifications. (The catch here is that the data to be downloaded needs to be generated from a manufacturer provided software as the internal layout and mapping of the device are still proprietary.) This software is cheap or free, but you need to contact the company, or find their ftp site on the internet. As part of the Lattice's GAL line of parts, there is an ispGAL22v10 part in 28 pin PLCC package. In the 1994 Lattice databook, there are sufficient information to download the part using the onboard serial interface. And, since it is a standard architecture supported by most logic compiler/assemblers, there isn't a problem with a proprietary interal layout. A free demo logic compiler/programmer package is available for some of the Altera EPX7xx parts from Xess Corp. (info at http://www.xess.com/) or files in the ftp://ftp.vnet.net/pub/users/xess/PLDshell/ directory. See the December 1995 Circuit Cellar Ink magazine for more details. 5. Classic Bipolar Fuse Programmed PALS from MMI, National, TI "A PAL Programmer" and "Getting Started with PALS" , Robert A. Freedman Byte, January 1987 A programmer for the original PAL family (too many to list). Implemented in the form of a IBM PC expansion card. (And sold for a while by Microway). Design is implemented with PALs. PAL Programmable Array Logic Handbook Monolithic Memories, 1981 or "Designing with Programmable Array Logic", Tech. Staff of Monolithic Memories McGraw-Hill, 1981 A hardback copy of the MMI databook, including the programming algorithms. Interface, Bipolar LSI, Bipolar Memory, Programmable Logic Databook National Semiconductor, 1983 Databook back when they still published the algorithms. The TTL Data Book, Volume 4, Bipolar Programmable Logic and Memory Texas Instruments, 1985 Databook back when they still published the algorithms. The IC Master, 1986 TI actually published some of the algorithms in the advertising pages in the Custom/Semicustom section. 6. AMD version of the classic PALS (Fuse Programmed) Programmable Array Logic Handbook Advanced Micro Devices, 1986-1987 This has the algorithms for the bipolar amPAL devices that existed at the time, including the amPAL22V10. These differ from the 1983 algorithms, which were preliminary. 7. PLS153, PLS159 from Signetics (Fuse Programmed) AN12, "Low Cost Programmer for PLD 20-Pin Series" Programmable Logic Data Manual Signetics, 1986 and 1987 A programmer for the low end 20 pin PLA family. Implemented in those devices. Device mapping for only two of the members. 8. PLS100, from Signetics (Fuse Programmed) "Programming p.l.d.s", V. Lakshminarayanan Electronics & Wireless World, January and February 1988 A circuit description for a programmer for the oldest Signetics PLA device. No Algorithm. Contact author for software. Bipolar and Mos Memory Databook Signetics, 1980 Algorithm desciption. (IMHO, why bother ;-) ) Finally, here's an edited note from Paul Hoepping about some German language articles on PLD programmers. (Thanks.) >Date: Thu, 31 Aug 1995 00:00:00 +0200 >From: Paul_Hoepping@citybox.fido.de (Paul Hoepping) >Subject: List of GAL-Programmer-Projects > >c't is a german computer and electronics magazine. It features mainly >articles on computer hardware, architecture and digital electronics. I do >not know if there is a english equivalent. > >elrad is a very professional german electronics magazine. It features all >kinds of digital and analog electronics and their theoretical basics. >There is no english equivalent. > >c't 9/90 and 10/90 >GAL Programmer for the 16v8 and 20v8. A plug-in PC card with many 74HC374 >drivers allows programming and testing. The software to this project has a >simple GAL assembler. Source text in Turbo Pascal. > >c't 12/92 >Update for the above programmer. Several different programming voltages >and modes. The programmers decides automatically on the voltage and mode >by reading and interpreting ID bytes. Some Information on GALs 16V8A, >16V8B, 20V8A, and 20V8B. No source text of the parts that actually do the >programming. > >c't 4/94 >Extension to a EPROM programmer project. This extension allows programming >of 16V8, 20V8, 22V10, GAL6001 in both normal, A, B-Version. Some >information on GALs. > >elrad 11/92 >very low cost programmer that uses the PC printer port. A 16V8 and a 20V8 >compensate for the differences in the pin out of the 16v8 and the 20v8. >This programmer can only do the old 16v8 and 20v8. > >elrad 5/94 >overview of all CPLDs and FPGAs and their development systems. > >elrad 7/94 >How to chose the right PLD for a design. > >elrad 10/94 >Starterkit for Lattice ispLSI1016, ispGAL22v10, and ispGDS14 >These new devices from Lattice are In System Programmable. You can get the >Lattice Development Software free of charge from the elrad BBS. Without >any instruction book hard to use. This version of the software can only >programm the smallest devices of the ispLSI family. If you want more you >need the full version that sells at DM 1500,-. Interesting. >By the way: the BBS has also a Version of PALASM, free of charge! > >elrad 5/95 >Presentation of the Lattice ispLSI CPLD family. > >elrad 1/94 >PLD development using easy-ABEL. Mark Zenier mzenier@eskimo.com mzenier@netcom.comArticle: 2718
I received a few requests to get a fax of the study "The Effect of Fixed I/O Pin Positioning on The Routability and Speed of FPGAs" by Mohammed A.S. Khalid and Jonathon Rose, Dept. of Electrical and Computer Engineering, University of Toronto. I was unable to fulfill all of the fax requests due to problems with the fax machines. However the paper is available on ftp, and I would encourage anyone who is interested to look there instead. (See below.) I also feel obliged to make 2 comments... 1) I apologize to anyone who may have been offended by my posting from January 16 1995. I can appreciate the value of the comp.arch.fpga newsgroup as an objective forum for discussion on topics of interest to the programmable logic, and in it's original intent, the reconfigurable logic community. So I hope I have not set a poor example of putting "marketing blah" on the public discussion newsgroup. I think it would have helped to have stated that the article was a published paper and to have not made any factual implications beyond exactly what was stated in the paper. As a member of a commercially competing firm, I recognize that it is especially important to be objective in such situations. Routing of FPGAs is a complex issue with many technical issues. It is not my intent to get into such a lengthy discussion, and I don't have the time to accept an invitation for further discussion on the issue. But I do apologize if I offended anyone. 2) The paper is actually interesting and stands on it's own merit. If you are interested to take a look, please get it off of ftp. The paper was presented at the 3rd Canadian Workshop on Field Programmable Devices (FPD '95), May 29 - June 1, 1995. The ftp address is: ftp.csri.toronto.edu. Please look for "techrep.ps" in the sub-directory "csri-technical-reports/325". Sincerely, Jason Feinsmith XilinxArticle: 2719
Dump the GALs, they are absolutely worthless and expensive. Go with PEELs. Contact ICT for literature. There was a PEEL programmer in Radio Electronics several years ago. It could burn 18CV8s. I use a BP MicroSystems PD1128 for burning PEEL/GALS/etc. It is a bit spendy, but it is industrial grade (I have burned several hundred thousand PEELs with no problems). PEELs provide a wide range of different Macro Cells, making them much more versatile than GALs. They are about .75 cents for an 18CV8 and about $1.75 for a 22CV10 (although I pay less than this for 1000+ quantities).Article: 2720
I need to program some MACH210's, I have a Sunshine EXPRO-80 universal programmer which is capable of programming them with the addition of a PLCC adapter socket. However, the cost of said adapter is unreasonable (to say the least, NZ$300) so I figure I can make my own. Can anyone supply me with info on which pins are used to program the Mach210 ? This, and any other information would be greatly appreciated.Article: 2721
In <DLwGsJ.Foo@world.std.com> jcooley@world.std.com (John Cooley) writes: > > >Frank, I think you're missing my point that this "ability" usually is >measured by how well one knows buzzwords like "Synopsys", "MOTIVE", >"DFT", "DSP", "Verilog" -- you've never had a headhunter call you up >asking if you know buzzword "XYZ"? You've never known engineers who >were hot career-wise because they knew these buzzwords or others who >weren't doing so well because they didn't have the right buzzwords? I've met too many people that have made the mistake of hiring on "buzzwords". They're not what makes the engineer. They may make it easier to make a decision, but they mean nothing to a good manager. Synthesis concepts are the same whether you're using Synopsys or Bulldozer or Silcsyn. HDL concepts are the same whether you use VHDL or Verilog. A good engineer can adapt to tools quickly. Just because you have had exposure to a synthesis tool doesn't mean I want you on my design team. As a matter of fact, there won't be any synthesis tools on the exam sheet I give an interviewing engineer. >Also, Frank, don't confuse the fact that right now engineers are >hired pretty much because they're what's available right now due >to the current 6 month shortage of them. Once the glut comes back, >it'll be disposable employee as usual. The "glut" in my experience has always been engineers that range from poor to mediocre who load their resumes with keywords to get interviews but then can't answer simple basic design questions when sitting in front of you at their interview. Every company that I've ever dealt with has always made it a practice to hire good engineers even through so called "gluts" or hiring freezes. If you're good you'll always be part of the exception, not part of the rule. "Tools" help build foundations but their nothing without the knowledge of how or why you're building the house... I go through hundreds of resume's that all have the great keywords on them. It's the one that has barely any but has much "content" that I'm always looking for. FGArticle: 2722
Hi, I am using MacABEL in classes and was wondering if anyone knew of a FAQ for ABEL or some more information about the language. Thanks in advance. -- Steve Lee Computer Engineering/Computer Science Iowa State University email -> sjlee@iastate.edu WWW -> http://www.cs.iastate.edu/~sjlee/homepage.htmlArticle: 2723
I have received a universal device programmer called PC-UPROG, which is made by Advantech. He bought it a few years ago, and now he has little use for it. Unfortunately, he can't find the disks with the software for it! Does anyone knows an FTP site or a Web site which has this software? If not, can anyone mail a copy of the software (I believe it's legal, since I *have* the unit, and the software is useless without the programmer!). thanks, UdiArticle: 2724
T. D. Bouvia (tdb@icf.hrb.com) wrote: : I am requesting any and all feedback regarding in-house training of : VHDL/Verilog. This could be tutorials, seminars, video tapes, etc... A slight basenote drift but does anyone know of a good Verilog course in the UK? Best Regards, Steve.
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