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
Hey, I am trying to get a Xilinx XC3064 fpga part up and running but I'm having some configuration problems. I'm trying to load the configuration data in master parallel mode. I can see the address lines changing, trying to look for the start bits. But when I put the EPROM in, the Xilinx chip starts sucking large amounts of current. I have my PS limited to 150mA so the supply voltage drops to about 2.8 volts. Any ideas????? It seems to have something to do with the data lines. I can put in an erased EPROM (all 1s) and it doesn't do it, but of course it won't configure. For some reason, the Xilinx wants to keep all of its data lines high all of the time. Something else that I noticed is that the address lines are all high for the first 80mS or so after powerup. Then the address lines start counting like their supposed to but quickly decay down to 2.7V (because of current limited supply). Help on this would be greatly appreciated! Thanks Jared Bytheway Center for Engineering Design University of Utah bytheway@ced.utah.eduArticle: 276
Does anyone know what FPGA architectures lend themselves to arthimetic operations such as a multiply? How fast can I run a 16 x 16 multilplier? _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/_/_/ _/ _/ Michael P. Hartnett _/_/ _/_/ _/ _/ _/ _/ Martin Marietta _/ _/ _/ _/_/_/ _/_/_/_/ 525 French Road _/ _/ _/ _/ _/ Utica, NY 13502 _/ _/ _/ _/ _/ USA _/ _/ _/ _/ _/ Phone: 315-793-7604 Fax: 315-793-7637 e-Mail:lcsmph@utica.ge.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/Article: 277
In article <CxInss.5Hz@ced.utah.edu>, >But when I put the EPROM in, the Xilinx chip starts sucking large >amounts of current. I have my PS limited to 150mA so the supply voltage drops >to about 2.8 volts. > Any ideas????? I have a 70A 5 volt supply in my closet that I use for just such an occasion. When connecting to your chip may sure you use a heat sink and 1/2 inch wide power rails. :-) Doesn't the chip spec sheet say that 150mA isn't enough power? Go to the store, and buy a cheap PC power supply.Article: 278
In article <CxInss.5Hz@ced.utah.edu>, Jared Bytheway <bytheway@ced.utah.edu> wrote: >Hey, >I am trying to get a Xilinx XC3064 fpga part up and running but I'm having some >configuration problems. I'm trying to load the configuration data in master >parallel mode. I can see the address lines changing, trying to look for the >start bits. But when I put the EPROM in, the Xilinx chip starts sucking large >amounts of current. I have my PS limited to 150mA so the supply voltage drops I knew someone who had exactly the same problem. I think he found out that he had the data lines hooked up in reverse order due to some screw-up in the documentation he had. Once he rearranged them, everything went along just fine. I could be mistaken about this since it was over a year ago, but you could call your XILINX representative and ask about it. -- || Dave Van den Bout || || Xess Corporation ||Article: 279
Has anyone used FPGA's to interface to a standard memory bus running at or above 40MHz ? (With the FPGA actually driving the bus lines) Thanks. Sanjay/ Actually most of these busses are spec'ed keeping in mind a fast technology. eg: Futurebus+ with BTL, VBus(from Vitesse?) with GTL etc for which a FPGA solution may not be viable, but even for a 5v TTL memory buss like Sun's Mbus, it gets quite tricky to drive the bus lines using FPGA's within the required spec. Thats why I was wondering if anyone has dealt with pure FPGA sols, to driving fast busses. vishin@devil.sun.comArticle: 280
CALL FOR PAPERS -- 1995 PLD DESIGN CONFERENCE April 25-27, 1995 Santa Clara, California At next spring's PLD Design Conference I am chairing a session devoted to all aspects of state machine design for PLDs and FPGAs. Proposals are hereby invited for papers relating to state machines. Suggested topics include (but are not limited to): -- case studies (real world designs) -- design and implementation techniques -- theoretical aspects of state machines -- asynchronous state machines If you are interested in presenting a paper, please contact me as soon as possible. A brief abstract would be appreciated. Deadline for proposals: October 20 Notification of acceptance: November 21 Approval of handouts: December 12 Final manuscripts due: February 27 Thanks for your interest! Steve Golson Trilobyte Systems 33 Sunset Road Carlisle MA 01741 phone: 508/369-9669 fax: 508/371-9964 email: sgolson@trilobyte.comArticle: 281
QUERYING THE ALTERA FLEX8000 FPGA FAMILY ARCHITECTURE ===================================================== The following assumes that you have a working knowledge of the FLEX8000 architecture. My question basically concerns how dependant the routability of the FLEX8000 is on the design pin-out. Most FPGA software will advise that you should (always) let the software choose the pinout in order to maximise routability. In practice one reaches a point where the pinout must be frozen to match a P.C.B design and one hopes that minor changes can still be made to the FPGA design while keeping a static pinout. To cope with practical design changes one expects the ROUTABILITY of an FPGA architecture to be relatively insensitive to the pin-out. A high level of routability should be achievable for an arbitrary pin-out (or at least a wide range of arbitrary pin-outs), despite the fact that the pin-out may result in poor timing performance because signals have had to follow unnecessarily long paths. My experience with the Xilinx LCA's seems to indicate that these devices (despite having what appears to be a fairly restrictive routing interconnect) display a good ability to make design changes with a fixed pin-out. SIMPLIFIED FLEX ARCHITECTURE (EPF8452 device) (Based on portrayal in data sheet) --------------------------------------------| 168 21 |---/------/--mux--IOE0 | | | | etc | | 21 168 | ---/--mux--IOE7 channel | row | ? . | | . | | -----------|-------------------|--|---------| | | | | | | / 24 | | | | | | LAB | | --------------|-----| | | | |LE0 |--- | | |-----| | | | etc | | | local |_____| | | interconnect|LE7 |------ |_____________|_____| LAB= logic array block LE= logic element (i.e registered or combinational equation) IOE= input/output element This diagram shows one of the rows (simplified). At one end of the row are eight IOE's (only IOE0 and IOE7 shown). One of the 21 LAB's is shown. In this LAB is eight LE's (only LE0 and LE7 shown) each of which drive a single line back into the row. There are 24 inputs from the row into the LAB. The SIMPLEST interperatation of this architecture suggests the following: - each LE is allocated a SINGLE channel which it can drive. - each IOB is allocated 21 channels from which it can choose one. *********************************************************************** Note: 21 LABs x 8 LE's = 168 channels 21 LABs x 8 IOE's = 168 channels This relationship also holds for the 27 column, 216 row channels device - however for the 13 column, 168 row channels device there appears to be a surplus of channels. *********************************************************************** Now for example this could mean that: LE0 in LAB0 can only drive channel0, LE1 in LAB0 can only drive channel1, and so on. IOE0 can only choose to connect to one of channels 0 to 20, IOE1 can only choose to connect to one of channels 21 to 41, and so on. Therefore IOE0 can only be directly driven by LE 0 to 7 from LAB0 LE 0 to 7 from LAB1 LE 0 to 4 from LAB2 (i.e first 21 LE's in that row) Of course the specific connectivety given here is just an example, but the point is that each IOE can only be directly driven by quite a small sub-set of the LE'S. (i.e 21 out of 168). This means that once an IOE is assigned to a specific output signal, then the logic that generates this signal becomes physically constrained to a particular sub-set of the LE's. Now this constraint is offset by that fact that the signal does not necessarily have to follow the most direct path from logic to IOE. It can find numerous other pathways through unused LE's, switching from row to column and column to row. However this introduces the possibility of degrading the timing excessively and it reduces the routing paths available for other signals. (These effects compound greatly when a large number of such paths need to be routed) I would expect this architecture would make the routability of FLEX8000 extremely sensitive to the pin-out, more so that devices like the Xilinx LCA's. That is just a gut-estimate however. If you had to make a minor modification to the logic of a highly utilized FPGA design with the pin-out fixed, I would expect the following. A Xilinx LCA would be more likely to be able to find a routable path but would generally give poorer timing. A FLEX device would generally give superior timing when routable, but would be less likely to find a routable path. In other words the FLEX is more likely to run into unresolvable routing restrictions if the pin-out is fixed. I emphasize again that this is only a gut-feeling based on the above architecture description. I could have misjudged the FLEX architectures' ability to get from arbitrary LE to arbitrary IOE in a highly utilized design. (Equally I could have misjudged the FLEX's ability to route tricky paths more efficiently that the Xilinx does on average - if one needs to go through several unused LE's and swap between row and columns several times in order to make a route then the FLEX fast-track starts to look as bad as the segmented Xilinx interconnect.) I have heard it suggested that one should leave 20% spare LE's and 20% spare IOE's in order to allow for design changes with fixed pin-out. In practice our designs tend to use 99% of the available pins. ALTERNATIVELY ------------- If the FLEX architecture is actually slightly different to that implied above, the routability (with pins fixed) could be much better. If instead of each LE only connecting to a SINGLE channel it actually has the ability to connect to one of several channels then the possible routing paths are increased. For example, if LE0 in LAB0 can connect to channels 0,21,41 (but perhaps only one at a time), this would mean that LE0 in LAB0 could directly connect to IOE0,1 or 2 rather than only IOE0. If each LE had the ability to drive one out of a selection of eight channels then any LE could directly drive any IOE the same row. This is a relatively small difference in terms of architecture (adds switch logic and increases loading) but the routability should increase dramatically. A similar result can be attained by adding more flexability at inputs to the IOE's rather then the outputs of the LE's. SUMMARY ------- To re-state my basic query, is the FLEX8000 architecture as I initially described it (i.e Each LE output is dedicated to a single row channel) or does it have enhancements like I have suggested (i.e Each LE output can drive one of several row channels)? The enhancements need not necessarily be on the LE outputs, they could be on IOE inputs or on column to row connections. But basically they provide the same effect of increased routing paths. Note that the inputs to the LAB's must have just this sort of enhancement since there are 24 inputs x 21 LAB's = 504 connections but only 168 channels and this suggests that (at minimum) each LAB input connects to one of three possible channels. (504/168=3). If anyone knows an E-mail address where I may get a definitive answer to such a query (i.e an Altera technical query hotline) I would appreciate it. Also any success or horror stories concerning the fittability of designs into FLEX8000 devices with fixed pin-out constraints may be enlightening. chris@labtam.oz.auArticle: 282
Jared Bytheway (bytheway@ced.utah.edu) wrote: : Hey, : I am trying to get a Xilinx XC3064 fpga part up and running : but I'm having some configuration problems. <snip> You may be loading the data in reverse order! There's master high and master low modes. If this is the case you don't need to reblow the eprom, just flip the state of the M1 input.Article: 283
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.Article: 284
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... DanArticle: 285
In article <37bon3$pdl@news.tv.tek.com>, bobe@soul.tv.tek.com (Bob Elkind) wrote: > > I don't know if Xilinx considers their .XNF file format (which is > entirely ASCII text) proprietary or not. > > If not, then they should be happy to provide you with a format > definition doc. If they consider it proprietary so as to protect it > from *others'* enhancements (e.g. the PC-ISA bus), then they should be > happy to give you a copy after you sign a non-disclosure agreement. > > If they consider it proprietary in the sense of *trade secret*, then > you have to sign a non-disclosure agreement or be a big-bucks customer > or both; or you can just decipher the "language" yourself and learn > from the error messages you get from the "other tools". > I believe that they *do* consider their .XNF file format to be proprietary (at least thats what the rep said when I talked to him earlier this year). However, they seem very reasonable to sign agreements with people from universities. Don't know exactly how much information you must supply. -- Larrie Carr Product Designer PMC-Sierra, Inc. Burnaby, B.C.Article: 286
I agree totally with chceking address lines, also rechekc that the file istself is ok, use the downlaod cable to laod it if you can temporarily reconfigure the circuit. DO NOT up the current limit, 150 ma should be more than plenty. You can destroy chips by bad config so caution is wise. Always keep my finger on the chip first time I trie a new board or file, might warm up just a bit but if is geeting hot you have about 5 seconds to kill the power. Any ham operator know the time constant, just about the same amount of time a plate glowing bright orange takes to melt and destroy the final ouput tube.... Also double check the config mode pins, they can also cause problems if floating. Pardons typos, in a non editing enviromnet. Martin Moeller mmoeller@delphi.com We do Video and Xilinx.Article: 287
In article <CxInss.5Hz@ced.utah.edu> bytheway@ced.utah.edu (Jared Bytheway) writes: >Hey, >I am trying to get a Xilinx XC3064 fpga part up and running but I'm having some >configuration problems. I'm trying to load the configuration data in master >parallel mode. I can see the address lines changing, trying to look for the >start bits. But when I put the EPROM in, the Xilinx chip starts sucking large >amounts of current. I have my PS limited to 150mA so the supply voltage drops >to about 2.8 volts. > Any ideas????? We had a simular problem with the AT&T version of the Xilinx FPGAs. We were not configuring them them the same way (we used serial from the host processor). The problem had to do with the write pulse timming latching up the part internaly... we did not figure it out until a we got a new data book... they changed the timming requirements... Anyway, the part got very hot because of the excess current draw. Maybe you have a simular problem..Article: 288
In article <CxC9E6.96B@latcs1.lat.oz.au> fulton@latcs1.lat.oz.au (John R Fulton) writes: >I require a few pics of the Xilinx LCA, CLB etc for an overview >of their architecture in my final year thesis. > >If anyone has any, or could tell me where to get some I would >be grateful. Otherwise I'll just have to draw them myself :(. > >Regards >John > >-- >John Fulton, STUD IEAust | Computer Science >Email: fulton@lucifer.latrobe.edu.au | and Electronic Eng >TEL: 853 9068 | La Trobe University > The Xilinx databook chapter 2 is full of diagrams on CLBS, routing and arrays. Is this what you want, or is it photomicrographs? All the best Philip FreidinArticle: 289
In article <CxInss.5Hz@ced.utah.edu> bytheway@ced.utah.edu writes: >Hey, >I am trying to get a Xilinx XC3064 fpga part up and running but I'm having some >configuration problems. I'm trying to load the configuration data in master >parallel mode. I can see the address lines changing, trying to look for the >start bits. But when I put the EPROM in, the Xilinx chip starts sucking large >amounts of current. I have my PS limited to 150mA so the supply voltage drops >to about 2.8 volts. > Any ideas????? >It seems to have something to do with the data lines. I can put in an erased >EPROM (all 1s) and it doesn't do it, but of course it won't configure. For some >reason, the Xilinx wants to keep all of its data lines high all of the time. >Something else that I noticed is that the address lines are all high for the first >80mS or so after powerup. Then the address lines start counting like their supposed >to but quickly decay down to 2.7V (because of current limited supply). > >Help on this would be greatly appreciated! > >Thanks > >Jared Bytheway >Center for Engineering Design >University of Utah >bytheway@ced.utah.edu Almost certainly what is wrong is that you are not giving the chip a valid bitstream. This is either because the data you are giving it is wrong because of address line or data line confusion, or because the data is not in the PROM the right way. The 80mS delay is normal, it is called housecleaning, and is the chip scrubbing the memory to a known state before programming. during this time the address lines are not driven, but have a light pullup resistor enabled. The chip looks for some leading '1' bits, followed by a bit pattern of 0010 followed by a length count. the 0010 is read left to right, in terms of what the chip is looking for, and the length count is expected msb first. See page 2-120 of the data book (1994). I am assuming that you are selecting parallel up mode, so the addreses start at 0. for master down, the data is the same, just the address sequence starts at ffff and counts down. Assuming you have a length count of 46112 (decimal), 0x00B420 (hex) here is what the start of your PROM MUST look like: msb lsb HEX addr 0 1 1 1 1 1 1 1 1 FF addr 1 0 0 0 0 0 1 0 0 04 (the 0 is the top 4 bits of LC, the 4 is the 0010) addr 2 1 1 0 1 0 0 0 0 D0 (the 0 is the next 4 bits of LC, and the D is the B of the LC) addr 3 0 1 0 0 0 0 1 0 42 ( the 2 is the 4 of LC, and the 4 is the 2 of the LC) addr 4 1 1 1 1 0 0 0 0 F0 ( the 0 is the lest sig nibble of LC, and the F is the dummy bits before the first data frame) addr 5 x x x x x x x 0 Xx ( the leat sig bit is the start bit of the first data frame, the rest is design dependant.) etc... As you can see, the data is sent MSB first, but is shifted from the LOW order end of the byte wide data comming from the EPROM. I.E. the first bit seen by the config logic is the LSB of ADDR 0. If data is not sent in correctly, then the chip miss configures, and contention usually occurs. This leads to high current drawn. Dont put a bigger power supply on this, fix the bitstream. At the start of configuration, all of the header upto and including the first dummy bit that follows the length count comes out of the DOUT pin. If you watch this pin amd the CCLK pin with a storage scope, or analyser, you should see the header in the sequence of 0010, 24 bit LC (MSB first), then constant high. If you see anything else, you have a problem. If the LC coming out is not what you expect, then check that you have the data lines connected up in the right order. Why have I written all this rather than pointing you at a manual you might ask??? Well it's because this is not documented well in any of Xilinx's current docs. To say this sucks would be being generous. This used to be well documented in the user guide and tutorial book, but is not in any of the current ones. Hopefully this will be enough to get you going. All the best, Philip FreidinArticle: 290
Jared Bytheway (bytheway@ced.utah.edu) wrote: : Hey, : I am trying to get a Xilinx XC3064 fpga part up and running but I'm having some : configuration problems. I'm trying to load the configuration data in master : parallel mode. I can see the address lines changing, trying to look for the : start bits. But when I put the EPROM in, the Xilinx chip starts sucking large : amounts of current. I have my PS limited to 150mA so the supply voltage drops : to about 2.8 volts. : Any ideas????? : It seems to have something to do with the data lines. I can put in an erased : EPROM (all 1s) and it doesn't do it, but of course it won't configure. For some : reason, the Xilinx wants to keep all of its data lines high all of the time. : Something else that I noticed is that the address lines are all high for the first : 80mS or so after powerup. Then the address lines start counting like their supposed : to but quickly decay down to 2.7V (because of current limited supply). How much is your Xilinx taking and how much is the rest of the circuit taking? May be your Xilinx is pushing your PSU over the limit during configuration. It would be normal for the PSU to drop the o/p voltage once it reaches current limiting. May be if you gave the circuit the current it requires you would be OK. This would be the first thing I'd check. Apart from that, make sure you are counting in the correct direction, ie if the mode pins are selecting MASTER PARALLEL UP then your data in the EPROM must match. Check the count direction using a logic analyser on the address pins for absolute confidence. Also check that none of the address/data lines are open circuit or short circuit. richard My views not those of my employerArticle: 291
Does anyone know what the latest version of PALASM is and if it is public domain? I'm unsure of the status of this and related software (eg. ABEL/CUPL) - are they p.d., shareware, proprietary or what? Any general info or ftp sites would be much appreciated! Thanks Graham -- -------------------------------------------------------------------- Graham Seaman, School of Computer Science, University of Westminster, 115 New Cavendish St. London W1M 8JS email: seamang@wmin.ac.ukArticle: 292
In article <CxM7nn.207@westminster.ac.uk>, seamang@westminster.ac.uk (Graham Seaman) writes: > Does anyone know what the latest version of PALASM is and if it > is public domain? I'm unsure of the status of this and related > software (eg. ABEL/CUPL) - are they p.d., shareware, proprietary > or what? Any general info or ftp sites would be much appreciated! The current version of AMD's PALASM is PALASM IV , rev 1.5a. This is AMD Copyrighted software. The sell it in the us through their industrial distributors for $125us. If you have a good relationship (Purchasing wise) with your AMD distributor or local AMD FAE, you can sometimes work out a better arrangement. Gerry BelangerArticle: 293
In article <CxM7nn.207@westminster.ac.uk> seamang@westminster.ac.uk (Graham Seaman) writes: >Does anyone know what the latest version of PALASM is and if it >is public domain? I'm unsure of the status of this and related >software (eg. ABEL/CUPL) - are they p.d., shareware, proprietary >or what? Any general info or ftp sites would be much appreciated! >Thanks >Graham The latest CUPL for PC is called TotalDesigner 4.5A I received this version update last week. By the way, the experience of my group with Logical Devices (we use CUPL and their logic programmer ALLPRO 88XR with fast PALCE and MACH devices) is a nightmare. Stay away from them! They are expensive, the CUPL has plenty of bugs, some of the manuals they ship with CUPL are years old, they know this and don't plan any update (sometimes they refer to non-existing chapters in other manuals). The ALLPRO 88XR comes with no manual, just a 30-pages handout. What's worst, their technical support is really lousy, I NEVER got an answer from them better than what I already guessed myself. DON'T MAKE OUR SAME MISTAKE! :-) >-------------------------------------------------------------------- >Graham Seaman, School of Computer Science, >University of Westminster, 115 New Cavendish St. London W1M 8JS >email: seamang@wmin.ac.uk Mauro Cerisola, OCRL Stanford UniversityArticle: 294
Having just debugged a similar problem, the cause was that the power supply rise time was sufficiently slow to cause the Xilinx internal power-up initialization circuitry to get confused. Quoting from the data book (fine print in a footnote!): "At power-up, Vcc must rise from 2.0 V to Vcc in less than 25 ms. If this is not possible, configuration can be delayed by holding RESET low until Vcc has reached 4.0 V (2.5 V for the XC3000L). A very long Vcc rise time of >100 ms, or a non-monotonically rising Vcc may require >6-us high level on RESET, followed by a >6-us low level on RESET and D/P after Vcc has reached 4.0 V (2.5 V for the XC3000L)." Our solution will probably be to hold RESET low during power-up. Has anyone else had similar problems? If so, what was your solution? ------------------------------------------------------------------ -- James C. LaLone Email: lalone@mc.com Mercury Computer Systems 199 Riverneck Rd. Tel: (508) 256-0052 x305 Chelmsford, MA 01824 Fax: (508) 256-3599Article: 295
this is in reply to "querying the altera flex 8000 architecture" ... information about this, and other, details can be obtained from the following sources: application engineering: tel (800) 800-epld application engineering: fax (408) 954-0348 marketing/training : tel (408) 894-7000 marketing/product : tel (408) 894-7104 customer service : tel (800) sos-epld literature : tel (408) 894-7144 bbs (<= 14k4, 8,1,n) : tel (408) 954-0104 i hope this is of some help. Stephen Smith home: sjsmith@netcom.com Product Planning Manager work: sjsmith@altera.comArticle: 296
I've (finally) gotten around to putting the list of FPGA-based Computing Machines on the Web. The URL is: List of FPGA-based Computing Machines http://bongo.cc.utexas.edu/~guccione/HW_list.html It currently lists over 40 research and commercial systems, with a few links to other appropriate Web pages. As always, new systems and corrections to existing entries are welcome. For those without World Wide Web access, I will continue to post a text version of this list to the comp.arch.fpga newsgroup semi-periodically. -- Steve Guccione -- guccione@ccwf.cc.utexas.edu -- 10/14/94Article: 297
####### ##### ##### # # ### ##### ####### # # # # # ## ## ### # # # # # # # # # # # # # # ##### # # # # # # ###### ###### # # # # # # # # # # # # # # # # # # # ##### ##### # # ##### ##### C A L L F O R P A P E R S THE THIRD ANNUAL IEEE SYMPOSIUM ON FPGAs FOR CUSTOM COMPUTING MACHINES Napa, California April 1995 For more information, refer to the WWW URL page: http://www.super.org:8000/FPGA/comp.arch.fpga PURPOSE: To bring together researchers to present recent work in the use of Field Programmable Gate Arrays or other means for obtaining reconfigurable computing elements. This symposium will focus primarily on the current opportunities and problems in this new and evolving technology for computing. SOLICITATIONS: Papers are solicited on all aspects of the use or applications of FPGAs or other means for obtaining reconfigurable computing elements in attached or special-purpose processors or co-processors, especially including but not limited to: ) Coprocessor boards for augmenting the instruction set of general- purpose computers. ) Attached processors for specific purposes (e.g. signal processing). ) Languages, compilation techniques, tools, and environments for programming. ) Application domains. ) Architecture prototyping for emulation and instruction. A special session will be organized in which venders of hardware and software can present new or upcoming products involving FPGAs for computing. SUBMISSIONS: Authors should send submissions (4 copies, 10 pages double-spaced maximum) before January 16, 1995, to Peter Athanas. A Proceedings will be published by the IEEE Computer Society. Specific questions about the conference should be directed to Kenneth Pocek. SPONSORSHIP: The IEEE Computer Society and the TC on Computer Architecture. CO-CHAIRS: Kenneth L. Pocek Intel Mail Stop RN6-18 2200 Mission College Boulevard Santa Clara, California 95052 (408)765-6705 voice (408)765-5165 fax kpocek@sc.intel.com Peter M. Athanas Virginia Polytechnic Institute and State University Bradley Department of Electrical Engineering 340 Whittemore Hall Blacksburg, Virginia 24061-0111 (703)231-7010 voice (703)231-3362 fax athanas@vt.edu ORGANIZING COMMITTEE: Jeffrey Arnold, Supercomputing Research Center Brad Hutchings, Brigham Young Univ. Duncan Buell, Supercomputing Research Center Tom Kean, Xilinx, Inc. (U.K). Pak Chan, Univ. California, Santa Cruz Wayne Luk, Oxford Univ. Apostolos Dollas, Technical Univ. of CreteArticle: 298
FINAL CALL FOR PAPERS FIFTH GREAT LAKES SYMPOSIUM ON VLSI March 16 - 18, 1995 * Buffalo, New York, USA SPONSORS: -------- IEEE Computer Society, IEEE Circuits and Systems Society, ACM SIGDA and The State University of New York at Buffalo. LOCATION: -------- Buffalo Marriott. The Buffalo/Niagara Falls metropolitan area is the second largest in the state of New York and offers many closeby tourist attractions. SCOPE: ----- The Great Lakes Symposium on VLSI is an IEEE and ACM sponsored annual event and has now become a truly international conference, attracting participants from all over the world. Original and unpublished articles on all aspects of VLSI are invited. Each article should clearly state its contributions which could be either theoretical or experimental. Major topics include but are not limited to: 1. Physical Design 2. Analog and Mixed Signal ICs 3. Memory Design 4. Testing, Design for Testability 5. Synthesis and Verification 6. Field Programmable Gate Arrays 7. Multichip Modules 8. Low Power Design 9. VLSI Technology 10. Specialized VLSI Architectures 11. Hardware/Software Codesign 12. High Level Synthesis SUBMISSION GUIDELINES: --------------------- Authors should submit FOUR COPIES of a review package which should include: * A TITLE PAGE containing title, most relevant topic number(s), name and affiliations of all authors(s), telephone number, Fax number and e-mail address of the author to whom correspondence should be sent. * A 50 word ABSTRACT. * An EXTENDED SUMMARY, not exceeding 2,000 words, describing the problem(s) addressed and its significance, techniques used and specific results. TUTORIALS: --------- Tutorial sessions are planned for March 18, 1995. Two page proposals on topics of current interest in VLSI are solicited. KEYNOTE ADDRESS: --------------- The keynote speaker will be James Meindl, Joseph M. Pettit Chair Professor of Microelectronics, Georgia Institute of Technology. IMPORTANT DEADLINES: ------------------- * Submissions must be received by Nov. 4, 1994. * Notification of Acceptance by Dec 19, 1994. * Camera-Ready Paper due by Jan. 18, 1995 (Proceedings published by IEEE Computer Society). MAILING ADDRESS: --------------- Program Chair, GLSVLSI 201 Bell Hall Dept. of Electrical and Computer Engineering The State University of New York at Buffalo Buffalo, NY 14260 FOR FURTHER INFORMATION: ----------------------- e-mail: glsvlsi@eng.buffalo.edu FAX:(716) 645-3656; Phone: (716) 645-2422 General Chair Program Chairs Local Arrangements ------------- -------------- ------------------ S. Chakravarty R. Sridhar & S. Upadhyaya V. Demjanenko (SUNY, Buffalo) (SUNY, Buffalo) (SUNY, Buffalo) Program Committee ----------------- J. Abraham C. Agagnostopoulos V. D. Agrawal (Univ. of Texas, Austin) (Kodak, Rochester) (AT&T Bell Labs) J. Cong W. Debany M. I. Elmasry (UCLA) (USAF, Rome Labs) (Univ. of Waterloo, Canada) E. Friedman D. Hill R. Jain (Univ. of Rochester) (Synopsys) (Univ. of Wisconsin) B. Kaminska S. Kang J. Oldfield (Ecole Polytechnic, Canada) (Univ. of Illinois) (Syracuse Univ.) C. Papachristou C. A. T. Salama E. Sha (Case Western Univ.) (Univ. of Toronto, Canada)(Univ. of Notre Dame) N. Sherwani S. Verdonckt-Vandenbroek (Western Michigan Univ.) (Xerox, Rochester) Steering Committee ----------------- N. Sherwani (Western Michigan Univ.)Article: 299
Graham Seaman (seamang@westminster.ac.uk) wrote: : Does anyone know what the latest version of PALASM is and if it : is public domain? I'm unsure of the status of this and related : software (eg. ABEL/CUPL) - are they p.d., shareware, proprietary : or what? Any general info or ftp sites would be much appreciated! I use Palasm ver 1.5a and MachXL version 1.3 I have always found AMD Technical Support very good, frequent well organised upgrades (I hope after saying that I am up to date 8-}) In the UK AMD have a person who liases with Universities and AMD have always helped education. I got an OHP set, sets of manuals etc when I ran a short course for Industry on PLd design. For a definitive answer to the "Public Domain" question contact Stuart Tindell of AMD. I think his number is 01925 830380. Basically if you buy one copy for the university to get the manual you can use the software in the University, but do talk to AMD about it. re PLD software; There was a copy of LOG/IC offered for use on the NET, see COMP.LSI.CAD faq, I got it, tried it and didn't like it. I have been using PALASM for years and for teaching purposes it is great, it has JK flipflop support with AMD's version of the PALCE610 and I use it to augment first and final year classes. The latest AMD MACHs are very useful CPLDs and although MACHXL is not the best CPLD fitter about it is easy to use. I have put a DRAM refresher and a UART for a 68000 into MACHs and have a guy working to put a big design into 5 or 6 MACHs connected together( Simulated sparately). This is unusual since bigger FPGAs would normally be used but my 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! I have used (read tried) abel, a very old version of Cupl and Orcad/PLD For my money ORcad/PLD was the best for simple PLDs. It uses a Dongle and costs money, hence my use of Palasm. I am away for a fortnight, email me then for further discussion. -- Regards from Ian McCrum, Lecturer in Digital Systems and ECAD Email: <IJ.MCCRUM@ulst.ac.uk> WEB: http://www.eej.ulst.ac.uk/index.html POST-MAIL: Department of Electrial & Mechanical Engineering University of Ulster at Jordanstown, Northern Ireland, BT37 0QB Tel: +44 232 365131 ext 2364 or at home +44 247 882889 Fax: +44 232 362804 or preferably +44 247 882894 ------------------------------ ends ------------------------------------ 8-}
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