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 <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: 2706Philipp, 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: 2710In 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: 2714I'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.com
Article: 2718I 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