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 <37o8i0$901@niaomi.iscm.ulst.ac.uk> ian@myhost.subdomain.domain () writes: >premise is that the very constraints Machs place on the designer produce >"better" designs and that MACHs are reprogrammable and cheap. The latest >MACH does not need a programmer, merely a lead to the parallel port and it >programs itself using JTAG signals; very neat trick! In-circuit programming is a very nice feature supported only by Lattice (probably among the first if not THE first), AMD, and Intel. In-circuit REprogramming is currently only supported by Lattice and AMD as far as I know. Intel/Altera's product line only uses OTP EPROMs right now although they seem to be getting close to finally releasing a Flash based in-circuit reprogrammable device. (Xilinx, of course, has had in-circuit configuration for a long time, but I don't know if it should be considered PROGRAMMING because the data is volatile.) I consider I.C.R.P. to be very important because gull wing PQFP packages offer a much higher pin count per square inch of board space than PGAs or PLCCs and gull wing packages have very delicate leads which are difficult to socket. It is best if you can solder it down directly to the board and never have to physically handle it again. I have stayed away from Altera's line of fairly interesting parts because they lacked this. They presumably bought Intel's product line to get access to this technology, among other things. I think the one-time programmable anti-fuse guys like Quick Logic and Actel will have problems providing cost-effective high pin count products because of this issue. The only hope I can see for them is plastic BGAs and good BGA sockets (if such are ever developed). Note that the BGA sockets don't have to be cheap as long as they have the same footprint as the BGA. The sockets would be used in development and the devices would be soldered down directly in production. -- Congratulations to the people who saved Mono Lake!Article: 301
In article <1994Oct15.175808.29253@adobe.com>, Phil Ngai <pngai@mv.us.adobe.com> wrote: >In-circuit programming is a very nice feature supported only by Lattice >(probably among the first if not THE first), AMD, and Intel. In-circuit >REprogramming is currently only supported by Lattice and AMD as far as >I know. Intel/Altera's product line only uses OTP EPROMs right now >although they seem to be getting close to finally releasing a Flash >based in-circuit reprogrammable device. I don't understand this. Altera/Intel FLEXlogic devices can have their SRAM reprogrammed at any time via the JTAG port. True, their EPROM is OTP, but you can override it at anytime by loading in a new design to the SRAM. >I have stayed away from Altera's line of fairly interesting parts >because they lacked this. They presumably bought Intel's product line >to get access to this technology, among other things. Can't figure this either. The Altera FLEX FPGAs (CPLDs to some) are also SRAM based and can be programmed in modes similar to XILINX parts. So they are in-circuit reprogrammable as well. Unless you are talking about MAX 5000 and 7000 parts which use the EPROMs. What am I missing here? What's the distinction between in-circuit programming and in-circuit reprogramming? -- || Dave Van den Bout || || Xess Corporation ||Article: 302
>Michael P. Hartnett (lcsmph@sn520.utica.ge.com) wrote: >: Does anyone know what FPGA architectures lend themselves to arithmetic >: operations such as a multiply? How fast can I run a 16 x 16 multiplier? > >I know a guy who was able to hook Twelve 16-bit multipliers on >to a 32-bit tri-state bus in ATT2C26 (the 26,000 gates ORCA >FPGA from AT&T). I think, the speed obtained was about 35 Mhz. > >Each instance was a special integer multiplier where you multiply >a variable by a constant and updating the constant requires a >multiplier to pause for sometime. (eg, see page 80 of EDN, May 1994) > >Satwant Arithmetic operations are a specialty of the Atmel AT6000 series FPGA. For more information contact Atmel Sales at 408 441 0311. If you use the macro generators included in the software for the Atmel FPGA, you can generate a fully functional pipelined 16x16 multiplier that runs at close to 30 MHz worst case. This multiplier is about 13,000 gates so I'm afraid we can't put 12 of them on our device :-) My view, of course, is biased as I work for Atmel. Scott Evans scott@atmel.comArticle: 303
I'm new to the FPGA world and I've noticed some things that I was wondering what you guys thought about. Some FPGA's (like Altera, Xilinx) have SRAM interconnects... so you can reprogram. Other FPGA's (like QuickLogic, Cypress) use "antifuse". They can't reprogram, but they boast that they have better routability and speed (antifuse has less cap than SRAM supposedly). What do you guys think (from experience) is the more useful technology? GarettArticle: 304
gbchoy@salsa.engr.ucdavis.edu (Garett B Choy) writes: >Some FPGA's (like Altera, Xilinx) have SRAM interconnects... so you can >reprogram. Other FPGA's (like QuickLogic, Cypress) use "antifuse". They >can't reprogram, but they boast that they have better routability and >speed (antifuse has less cap than SRAM supposedly). What do you guys >think (from experience) is the more useful technology? 1. Altera makes both RAM-based (reconfigurable) and non-RAM based (i.e. one-time-programmable) FPGAs. 2. I'm not familiar with *all* the non-SRAM based FPGAs, but in the list of SRAM-based FPGAs you should include ATT/ORCA in the list, since the list is fairly short. 3. Don't ignore the fundamentals of various technologies (e.g. anti-fuse, SRAM, RISC, CISC, segmented, etc. etc.) *BUT* ... When all is said and done, buy performance and not promises. Execution (i.e. implementation) is a large part of the *delivered* performance, and often overcomes "fundamental advantages" in competing products. Examples: x86 vs. 68K (who has more/better software?) *nix vs. Windows vs. OS/2 (more/better/cheaper apps?) conventional internal combustion vs. rotary engine (mileage?) etc. etc. 4. Don't forget the importance of decent design/development tools! 5. If you can get the job "done" with an FPGA that someone you know has already used (successfully), that would be a very compelling consideration (for me). Having someone nearby who has already gotten the software and hardware debugged and running, and can advise you when (*not if*) you run into roadblocks), is a *very* valuable asset, much more so than a pile of anti-fuses (or SRAM). I see from your net address that you are probably a student (correct me if I'm making a rash assumption). The tradeoffs for a one-time experiment or demonstration project are *very* different than the tradeoffs for a commercial product development. Your interests are likely to be very short-term; learning curve and toolset cost may very well outweigh factors such as volume-manufacturing-cost, product family extension, toolset migration paths, etc. Your mileage *will* vary. Good luck in your project. Bob Elkind, Tektronix TVArticle: 305
One more thought on "one time" vs reuseable parts. Even though you have a pile of "one time" parts on the bench you KNOW that they each are $50 ( or whatever). This sometimes keeps you from making a quick "debugging" change to a part. With a SRAM part (Xilinx) it is easy to do a quick change to debug a problem, if you know you are smoking $50 you tend to hesitae and waste time. I know that it is not "rational" but I suspect most of us would do the same. ( You know you have this prblem when you catch yourself wiring a 7404 onto a board to "fix" a polarity of a PAL output instead of remaking the part) Martin Moeller mmoeller@delphi.comArticle: 306
In the previous discussion on in-circuit programming, no one mentioned the ATMEL 6000 device which also has SRAM based reprogrammability. In fact they claim that they have the only product that supports reprogramming while the device is in operation! George Kiss Open University, England g.r.kiss@open.ac.ukArticle: 307
In article <1994Aug19.071146.11374@adobe.com>, pngai@mv.us.adobe.com (Phil Ngai) writes: > Any Synario users out there? I'd like to know who else responded. I'm an editor for Personal Engineering magazine and I'd like to hear about users experiences, especially difficult development situations, creative solutions and the like. Thanks. Russ LindgrenArticle: 308
In article <330v0t$72t@feynman.ee.latrobe.edu.au>, lurch@ee.latrobe.edu.au (Geoffrey Liersch) writes: > The Xrisc-4000 processor is a 16 bit RISC computer developed in the Department of Electronic Engineering at La Trobe University by Geoff Liersch Geoff, I'd like to know more details about the project, specifically I might be interested in an article that details your development. I'm an editor for Personal Engineering Magazine and I'm frequently looking for interesting contributed articles... Please email if you're interested. ThanksArticle: 309
In article <34593c$7q@panix2.panix.com>, rodneym@panix.com (Rodney Myrvaagnes) writes: > In <1994Sep1.154114.14217@peavax.mlo.dec.com> >arthur@alcor1.mlo.dec.com (Ed Arthur) writes: >Intel sold its PLD business to Altera. It probably does not support >PLDshell any more. I've spoken with Bob Beachler, mkt manager at Altera. He says that Altera will *continue* to support PLDshell as a FREE product If you'd like to get a free copy, call Altera at 800 443-7610 Hope this helps. Also, if you have problems, email info to me.Article: 310
In article <37smb0$kis@elvis.vnet.net> devb@elvis.vnet.net (David Van den Bout) writes: >What am I missing here? What's the distinction between in-circuit >programming and in-circuit reprogramming? I may have chosen my terms poorly, but what I am concerned with is whether the part loses its brains when it loses power. For me, it's a lot more convenient if I can "program" the part using a dedicated tool and not have to provide extra hardware at extra cost to reload its brains whenever power is lost. The Xilinx parts are not too bad because it's usually a single chip solution. The Altera 8000 parts look similar to Xilinx in this respect, although I haven't personally used them. The current INTEL parts are not. I think I would use three terms: in-circuit configuration. Like Xilinx and Altera 8000, the information loaded is volatile and must be loaded every time power is lost. in-circuit programming. The current Intel parts, based on One Time Programmable EPROMs. You only get to program it once. in-circuit reprogrammable. Configuration is non-volatile and can be reprogrammed a reasonable number of times. When silicon people talk about "programming" a device, I believe it is in the non-volatile sense, but I could be wrong. For example, you "program" a PROM or EPROM. You "load" an SRAM. -- Congratulations to the people who saved Mono Lake!Article: 311
RLPersEng (rlperseng@aol.com) wrote: : In article <330v0t$72t@feynman.ee.latrobe.edu.au>, lurch@ee.latrobe.edu.au : (Geoffrey Liersch) writes: : > The Xrisc-4000 processor is a 16 bit RISC computer developed in the : Department : of Electronic Engineering at La Trobe University by Geoff Liersch : Geoff, I'd like to know more details about the project, specifically : I might be interested in an article that details your development. : I'm an editor for Personal Engineering Magazine and I'm frequently : looking for interesting contributed articles... Please email if : you're interested. Thanks Geoff, I would be interested in your work as well. What is available in the form documentation, white papers, etc.? If you could please e-mail me regarding this, I would appreciate it. I am currently engaged in the research and development of reconfigurable hardware systems in general, and reconfigurable processors specifically. -- Jeff Hutchings ====================================================================== Jeff Hutchings Director Of Engineering Metalithic Systems, Inc. (MSI) ====================================================================== e-mail: hutch@metalith.com ======================================================================Article: 312
In article <G8s@hpgndlab.grenoble.hp.com>, cam@grenoble.hp.com (Daniele Beccari) writes : >Hello, I have some questions about the best ways to exploit ALTERA >EPLDs, but I don't know if this is the appropriate newsgroup (fpga != eplds...) > >Thanks for suggestions... > >Dan > I think this is a good idea to include the ALTERA EPLDs in this newsgroup. Guillaume.Article: 313
In article <1994Oct18.013457.15054@adobe.com>, Phil Ngai <pngai@mv.us.adobe.com> wrote: .> .>I think I would use three terms: .> .>in-circuit configuration. Like Xilinx and Altera 8000, the information .> loaded is volatile and must be loaded every time power is lost. .>in-circuit programming. The current Intel parts, based on One Time .> Programmable EPROMs. You only get to program it once. .>in-circuit reprogrammable. Configuration is non-volatile and can be .> reprogrammed a reasonable number of times. .> OK, I understand what you mean by in-circuit reprogrammable devices now. On the above statement, however, I would place the Intel FPGAs into both the "in-circuit configuration" and "in-circuit programming" since they can be configured either using their OTP EPROM or their SRAM. It's a minor point. -- || Dave Van den Bout || || Xess Corporation ||Article: 314
In article dg1@magus.cs.utah.edu, jlhutchi@sal.cs.utah.edu (Jeff Hutchings) writes: > Geoff, I would be interested in your work as well. What is available in > the form documentation, white papers, etc.? If you could please e-mail > me regarding this, I would appreciate it. I am currently engaged in > the research and development of reconfigurable hardware systems in > general, and reconfigurable processors specifically. > > -- Jeff Hutchings Geoff, please just post the info! Thanks. --- ~ Bill Wolf, Raleigh NC ~ I can see ~ ~ wolf@aur.alcatel.com ~ the fog ~ ~ My opinions, NOT my employer's ~ at the end of the tunnel ~Article: 315
In article <g.r.kiss-171094233522@assante.open.ac.uk>, George Kiss <g.r.kiss@open.ac.uk> wrote: >In the previous discussion on in-circuit programming, no one mentioned the >ATMEL 6000 device which also has SRAM based reprogrammability. In fact >they claim that they have the only product that supports reprogramming >while the device is in operation! Not exactly. The Intel/Altera 8160 has two halves which can be independently reconfigured without affecting each other's operations. This is admittedly not as powerful as what can be achieved with the Atmel FPGAs (at least according to their marketing literature; I've never actually used one). -- || Dave Van den Bout || || Xess Corporation ||Article: 316
I am using Mentor Graphics and XC4000 parts but cannot find a symbol for a 16x2 ROM. There are symbols for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM. The problem is that when I place two 16x1 ROMs on the schematic there are not placed into the same CLB even though they should fit (have same address lines). Does anyone know how I can make a 16x2 ROM with these parts? - Russell Petersen petersr@fpga.ee.byu.eduArticle: 317
I implemented a full 8X8 multiplier in the Altera FLEX 8000 family. It is just an experiment and no particular effort was made to optimize it. It is not pipelined and its propagation delay pad to pad (thus including the delay to get inside and then out of the device) is better than 90 ns (we don't have a licence for the static timing analyzer here, so this is from many direct simulations). It only used 60% of the smallest FLEX (125 logic blocks out of 208, the smallest FLEX is 2500 gates) and my results are valid for the -2 device (there are faster devices now, the A series). The good thing is that the whole design, that was expressed in high level language (AHDL), took only 70 seconds to compile, synthetize, write a backannoteted VHDL netlist, place and route. For me that I had to use Mentor tools :-( during my previous gate array designs, this is really good. I haven't tried a 16X16 multiplier, but it shouldn't be more than 5-6 times bigger than the 8X8 one. Pipelining should make it pretty quick and shouldn't increase the size by a big deal since all the FLEX logic blocks have flip-flops already whether you use them or not. No, I don't work for Altera, but I like their tools and I'm even trying to get a personal copy for hobby. Enzo -- Vincenzo Liguori | enzo@research.canon.oz.au Canon Information Systems Research Australia | Phone +61 2 805 2983 1 Thomas Holt Drive, North Ryde, NSW 2113 | Fax +61 2 805 2929Article: 318
Hi, I am wondering if it is possible to use DQN type photoresist at 313 nm wavelength. The Hg bulb does emit at this wavelength. Is any one out there using this wavelength for lithography purpose? What kind of problems would i be facing. I know that the bleaching at this wavelength is low compared to 365 nm or 435nm. So contrast could be a problem. But how serious is this problem? Thanks a lot. saurinArticle: 319
At last we got the release 5.0 of the xilinx tools!!! We started to convert a design done with the 4k libs to the new unified libs. We noticed that the disign now needs a lot more CLBs than it used with the old libs. The reason for this is that the clock enable input of the CLB flipflops isn't used and the CE feature is realised using the LUT. We just had to modify some counters and regs to bring the design to a reasonable CLB count. If someone has similar observations we would be verry interested to hear. An other problem is still alive. If you use the carry logic it happens that sometime the ppr is putting some other signals to the dedicated carry inputs of the LUT. Wath makes things worse with the new release is that the simulation is based on your schematics and not on the xnf file that results from the routing. So you have no chance in detecting the errors introduced by the ppr prior to loading the design into the HW. If anyone made similar observations we would like to know. And if there is any work arround other than manualy correct the design in XDE it would be verry wellcome. Thanks for any help! Edi ***************************************************************************** Swiss Federal Institute of Technology * Email: edi@ife.ee.ethz.ch Electronics Laboratory * High Performance Computing * Edi Hiltebrand * Tel: +41 1 632 27 61 8092 Zurich, Switzerland * Fax: +41 1 632 12 10 *****************************************************************************Article: 320
In article petersr@fpga.ee.byu.edu (Russell Petersen) writes: > I am using Mentor Graphics and XC4000 parts but >cannot find a symbol for a 16x2 ROM. There are symbols >for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM. >The problem is that when I place two 16x1 ROMs on the >schematic there are not placed into the same CLB even though >they should fit (have same address lines). Does anyone know >how I can make a 16x2 ROM with these parts? It may not be a big deal, since ROMs are really nothing more than a combination of logic gates. Looking at it this way, there is no *inherent* reason for the 2 bits of your ROM to be combined in the same CLB, other than the fact that the two function generators share 4 input signals. So, PPR treated your "ROM" just as casually as any other gates it finds. I believe that in XACT 5 there is a provision for grouping logic together, short of the RPM construct. If all else fails, go for the RPM (Relationally Placed Macro) which is designed for just this sort of problem. Bob Elkind, Tektronix TVArticle: 321
We have just made available a WWW Home Page for the USC Multiprocessor
Testbed Project. The link is:
http://www.usc.edu/dept/ceng/dubois/testbed.html.
The USC Multiprocessor Testbed Project is exploring a new approach for
the rapid prototyping and performance evaluation of multiprocessor systems.
The methodology is based on hardware emulation and relies on emerging FPGA
(Field Programmable Gate Array) technology. Our first emulator, called the
USC Multiprocessor Testbed, is an 8-processor reconfigurable machine. It was
designed and built in 15 months. The Testbed can emulate a large class of
systems including shared and distributed memory multiprocessors, CC-NUMAs,
COMAs, various cache protocols and consistency models.
The home page contains links to general information on the project,
pictures of the machine and papers/slide presentations.
For further information please contact Michel Dubois (dubois@paris.usc.edu)
or myself - Luiz Barroso (barroso@paris.usc.edu).
Article: 322We just added support for verilog for our EVC product I got help from Xilinx who uses Synopsys and that all works. The problem is verilog itself doesn't let you put pin numbers so in Synopsys you use a script file by putting set_attribute sclk "pad_location" -type string P57 The question is how is this done with Cadence? I know I could put the pinouts in a .cst file but I'd like to have it done with just the Cadence tools. Steve Casselman Virtual ComputerArticle: 323
In article <383f5r$3a1@news.tv.tek.com>, bobe@soul.tv.tek.com (Bob Elkind) writes: |> In article petersr@fpga.ee.byu.edu (Russell Petersen) writes: |> |> > I am using Mentor Graphics and XC4000 parts but |> >cannot find a symbol for a 16x2 ROM. There are symbols |> >for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM. |> >The problem is that when I place two 16x1 ROMs on the |> >schematic there are not placed into the same CLB even though |> >they should fit (have same address lines). Does anyone know |> >how I can make a 16x2 ROM with these parts? |> |> It may not be a big deal, since ROMs are really nothing more than a |> combination of logic gates. Looking at it this way, there is no *inherent* |> reason for the 2 bits of your ROM to be combined in the same CLB, other than |> the fact that the two function generators share 4 input signals. |> |> So, PPR treated your "ROM" just as casually as any other gates it finds. |> |> I believe that in XACT 5 there is a provision for grouping logic together, |> short of the RPM construct. If all else fails, go for the RPM (Relationally |> Placed Macro) which is designed for just this sort of problem. |> |> Bob Elkind, Tektronix TV I found at least one method (besides RPMs) that seems to work well although it is a bit tedious. Giving two ROMs the same HBLKNM causes them to be placed into the same CLB. I used this method and was able to implement an 8 bit constant multiplier with the ROMs that operates at 21 Mhz. I used the design described in an EDN article a while back. The great thing about these multipliers are that they only take 22 CLBs for 8 bit multipliers. The reason they work so well is due to the speed of the lookup tables on the Xilinx parts (and probably any other part using lookup tables). This only works however for constant multipliers. Any general multiplier is probably best implemented as a full array unless you can afford the time it takes to change the constant. - Russell Petersen petersr@fpga.ee.byu.eduArticle: 324
Hello there, I would like to ask if anyone out there has had experience of or solved a problem specific to particular suite of FPGA development software. We have a problem with the Xilinx FPGA software. We have OrCAD, Xact and the OrCAD interface to Xact, for developing XC2000, XC3000 and XC4000 series FPGA's. Recently, we decided to use Xilinx Abel to embed 'components' created using XAbel in OrCAD schematics. These components are used to implement circuitry that does not lend itself well to schematic representation, such as one-hot encoded state machines. The normal way of doing this is to compile the Abel components into individual .XNF files using XAbel, compile the schematics in which they are embedded into an .XNF file using the Orcad interface, and perform an XNFMERGE on the schematic .XNF file, which pulls in the .XNF's for the Abel components and flattens everything. However, we have found that when we run XNFMAP on the merged .XNF file, it fails to optimise the logic as well as it should. This only seems to happen when we use Abel components. This is the merge-then-map method. Should we be mapping each .XNF file before merging the .MAP files? (map-then-merge) I am sure that this would produce worse results as the partitioning of logic is best done with knowledge of the entire FPGA circuitry. For example, in a development version of an Abel file, we might feed a certain input straight through to an output. One would expect the software to simply join the two nets. However, what actually happens (sometimes) is that an entire CLB is used merely to feed the signal through (with a function generator such as F=A being used), adding to propagation delay. As some nets are fairly timing critical (i.e. a clock speed of 33 MHz with an XC3042-100 part used in a synchronous circuit), this is not acceptable. We have tried using Abel components in a trivial circuit, and it appears to optimise these OK. When a 'real' circuit is used, it does not manage to optimise nearly as well as it should. This behaviour does not occur if we do not embed any Abel generated components in the schematics. So, it looks like that we are stuck with drawing out state machines as logic gates for the moment. Any ideas? Xilinx technical support did not manage to help us. Sorry for such a long and tedious posting - I hope I have managed to explain the problem sufficiently well in the space available in a usenet posting. Any help would be greatly appreciated. Thanks, Tomas Whitlock.
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