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
spp@bob.eecs.berkeley.edu wrote in article <5tke6f$fhc$1@samba.rahul.net>... > MaxPlus2 works well in general but I have a few complaints: > > (1) It has a habit of overwriting your design input files > (e.g. *.acf, maxplus2.ini). So, for consistent results you > must keep extra copies of these and write a script > that copies them into the relevant directories. This seems to be a common mistake people make. The .acf file is kept in memory until Maxplus2 is closed or a new project is loaded, at which point its written out to the drive. You can't make changes to it while your project is open because when you close the project, Maxplus2 writes the .acf over your changes. The safest way to make changes to the .acf is to close Maxplus2, make the change and then reopen it. -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 7301
Richard Iachetta <iachetta@us.ibm.com> wrote: >spp@bob.eecs.berkeley.edu wrote in article >> [MaxPlus2] has a habit of overwriting your design input files >> (e.g. *.acf, maxplus2.ini). So, for consistent results you >> must keep extra copies of these and write a script >> that copies them into the relevant directories. > This seems to be a common mistake people make. The .acf file > is kept in memory until Maxplus2 is closed or a new project is > loaded, at which point its written out to the drive. You can't > make changes to it while your project is open because when you > close the project, Maxplus2 writes the .acf over your changes. > The safest way to make changes to the .acf is to > close Maxplus2, make the change and then reopen it. I run maxplus2 in batch mode exclusively, therefore I don't use its feature of "opening" a project, therefore do not encounter the situation you describe. But it remains unreasonable for a CAD tool to overwrite the designer's input files. It should put its output somewhere else. SteveArticle: 7302
In article <01bcaf24$890e9910$b6433509@gaia>, Richard Iachetta wrote: >spp@bob.eecs.berkeley.edu wrote in article ><5tke6f$fhc$1@samba.rahul.net>... >> MaxPlus2 works well in general but I have a few complaints: >> >> (1) It has a habit of overwriting your design input files >> (e.g. *.acf, maxplus2.ini). So, for consistent results you >> must keep extra copies of these and write a script >> that copies them into the relevant directories. > >This seems to be a common mistake people make. The .acf file is kept in >memory until Maxplus2 is closed or a new project is loaded, at which point >its written out to the drive. You can't make changes to it while your >project is open because when you close the project, Maxplus2 writes the >.acf over your changes. The safest way to make changes to the .acf is to >close Maxplus2, make the change and then reopen it. This problem is actually well described in the online help in Maxplus2. You don't have to close your project or Maxplus2 in order to update the .acf file from disk to memory. I myself often make changes in the .acf file with an text editor, because I find the menu based pin assigment cumbersome. The golden rule for making changes to the .acf file is: You can only make changes in _either_ the .acf file or by using the assign menu in maxplus2, between each recompile. If you choose to make some changes in the assignments using the menus, then perform a recompile (or a "check design") in order to force Maxplus2 to write the changes to the .acf file. Now you then open the .acf file, you can see your assignments and make new assignments directly in the .acf file. These changes are the read by Maxplus2 in the next recompile (as long as you at the same time, don't make new assignments from within maxplus). -- Sten Soegaard Aalborg University, Denmark Currently designing a Flex10k50 based testboard for testing various microprocessor designs.Article: 7303
> spp@bob.eecs.berkeley.edu wrote in article > <5tke6f$fhc$1@samba.rahul.net>... > > MaxPlus2 works well in general but I have a few complaints: > > > > (1) It has a habit of overwriting your design input files > > (e.g. *.acf, maxplus2.ini). So, for consistent results you > > must keep extra copies of these and write a script > > that copies them into the relevant directories. > > This seems to be a common mistake people make. The .acf file is kept > in > memory until Maxplus2 is closed or a new project is loaded, at which > point > its written out to the drive. You can't make changes to it while your > project is open because when you close the project, Maxplus2 writes > the > .acf over your changes. The safest way to make changes to the .acf is > to > close Maxplus2, make the change and then reopen it. > [M.Vorbach] I´m sorry, but this is not a common mistake people make. This is a stupid mistake ALTERA make. It seems crazy, that I have to close the whole programm to change the .acf and than reload it. Seems to be vary incapable programmers. >Article: 7304
On Fri, 22 Aug 1997 09:32:12 +0100, Tim Forcer <tmf@ecs.soton.ac.uk.nojunk> wrote: >Terry Harris started a thread: > >>>> Lattice parts .. global routing pool ... undocumented limitations, >>>> when you lock down pins and the fitter can't fit .... > >To which Steve Darby added comments including: > >>> The Lattice parts also have a Output Routing Pool (ORP), which can route >>> any the output of a GLB to any of a set of pins. This is where I found >>> the fitter was running out of resources. Each GLB has a set of >>> associated pins where the ORP can be bypassed, but the fitter was too >>> dumb to assign GLBs to bypass the ORP (even though I assigned the GLBs, >>> the fitter would move them and it wouldn't fit). After some searching, >>> I found I could designate the output as CRIT, the fitter finally >>> bypassed the ORP, and it routed. > >Then Ed Barrett commented: > >> Maybe you just didn't know how to best utilize the fitter! Pins can be >> fixed in the source file (schematic or VHDL), with a seperate pin file >> or in the most recent Lattice fitter by point and click. In the last >> case a window opens showing the signal names - you click on the signal >> name than click on the pin shown on the package diagram. I don't know >> what could be easier. I have not seen any issues with Lattice parts >> pin-lock performance even at very dense utilization. They also have an >> app note benchmarking pin locking performance on their web page at >> http://www.latticesemi.com. > >Tim Forcer added: >Read Steve's post more carefully. Steve DID know all about locking >pins, his problem was that he had to lock the GLB, the pin, AND the >interconnect between them before the fitter would come up with the right >answer. A different problem to the one you comment on, but very >significant given the architecture. Using Lattice's TERRIBLE pDS >software I ended up fixing just about everything, so the fitter had >almost nothing to do. Even most of the logic was sorted outside pDS. >That way I knew what I was getting and how it was derived. (Note that >when Lattice recently updated pDS, they didn't even bother to tell me, >despite my pDS being a full-price, registered copy. Unless the new one >is a vast improvement, I'm not sure it would be worth upgrading anyway.) > >A secondary issue with Lattice (and many other CPLDs) is that despite >all these routing pools, the silicon is arranged in blocks of blocks, so >there is no way (with the bigger parts at least) that you can have >totally free pin assignment. I'm not knocking the architecture - it has >a lot of good points - but it isn't, and can't be, a total solution. > Just a FYI- I spoke to the Lattice FAE yesterday - actually, he called me out of the blue - maybe he read my post ;^} ! Anyway, Lattice is coming out with an update to the Synario Product, version 5 in September. One of the many issues that it supposedly addresses is the performance of the fitter. The way it was described to me was that it will produce a spreadsheet of options to control the fitting and pin-locking process. Can't wait to see what it is and how it works - contact your Lattice rep for additional information. More about this later, when I try the new software. Steven J. Ackerman, Consultant ACS, Sarasota, FL sja@gte.net http://www.acscontrol.comArticle: 7305
On Fri, 22 Aug 1997 13:19:23 -0400, Botond Kardos <nobody@nowhere.com> wrote: >Oops, I've almost forgot to mention that besides their routing >problems I do like Lattice PLDs. They're fast (consume a lot :< ) and >the ISP is quite easy with them. > >-- >Kardos, Botond - at Innomed Medical Ltd. in Hungary >eMail: kardos@mail.matav.hu >phone/fax: (0036 1) 351-2934 >fax: (0036 1) 321-1075 I too like these parts, although there have been many times that I wish that I had one more I/O or GLB available in the same package. Steven J. Ackerman, Consultant ACS, Sarasota, FL sja@gte.net http://www.acscontrol.comArticle: 7306
Wayne Turner wrote: > > Roger, > > The following is from the Altera web site (www.altera.com) and was found by > searching on the word "socket" in the solutions database. Hope this helps... > > Wayne > > Begin included text -------------------------------------------------------- > > Sockets for 503-pin PGA packages are shown below: > > Zero-Insertion-Force Sockets > ============================ > Vendor Part Number Type Price Phone Number > --------------------------------------------------------------------------- > AMP 382876-6 Note (1) --- (800) 522-6752 > (800) 331-9857 x05410 > Yamaichi NP-236-102002-AC01601 Lever Arm $220 (408) 456-0797 > 3M/Textool 2-0503-01357-050-019-002 Lever Arm $350 (800) 3M-HELPS > (800) 421-2244 > End included text -------------------------------------------------------- > > > In article <33F334B7.7F9E@net.polyu.edu.hk>, > "Yau Man Wai , Roger" <rogeryau@net.polyu.edu.hk> wrote: > >Hello, > > I ordered a Altera 10K100GC503. I have search for AMP amd > >3M but no such high pin counts PGA socket for this device, does > >anyone know where can I order a 503 pins PGA socket for this device? > >Thank you! > > > >Roger Yau > >R & D Engineer > >Easson Precision Ltd. > >http://www.net.polyu.edu.hk/~rogeryau Try www.samtec.com ...Article: 7307
Austin, we have a customer who has passed the PCI-SIG Compliance Workshop last July; this included working behind DEC bridges. So far, it's always been a software issue when devices using our LogiCORE PCI macro don't work behind a bridge. We have not seen any issues between our macro and PCI-PCI bridges. However, if you are seeing a problem with our macro, contact me directly, and I'll work to resolve it. I'm glad you found some info about using the model_io perl script. If you would like a copy of the documentation that describes this, it's available on-line in the v1.1 User's Guide at: http://www.xilinx.com/products/logicore/pci/pcilit.htm Jim McManus Xilinx PCI Applications Engineer Austin Franklin wrote: > I finally found someone at Xilinx who 'explained' what was going on in the > simulations... > > He said that the timing numbers that are in the simulation file are > 'extremely conservative' and they have a perl script that I have to run on > the back annotated .xnf file to put in the 'databook' numbers. > > So, I ran this script, and now my simulation works fine....but the actual > silicone still doesn't work behind a DEC bridge...and when we try to probe > it...it works... > > So, next question is has anyone tested out their Xilinx PCI design behind a > PCI bridge?Article: 7308
Hello everyones,
I buy in an amateur radio flea market an "EPLD device
programmer for 16V8, 20V8 and 39V18".
These chips are in the PAL/GAL family.
The company who made that programmer is ROYAL Electronics, it's
written "Made in Canada" in the back, and the model mumber is EV6000.
In the top of the programmer we have a 24 pins ZIF socket, it's a one
device programming box.
I check the date code of the chips inside and it's in the mid 80's.
(1984-1986)
It's written on the PC board REA
1986
/---------\
And also the following sign < MPC >
\---------/
We have also a flat ribbon cable with a DB-25 male connector on that
programmer.
I check for the various signals at the programmer side:
Pins 2 to 9 are connected to a 74LS373 at the various inputs of that
multiple D flip-flop chip.
Pin 12 is connected to a 16V8 Gal chip pin 14.
Pins 20 to 25 are at the ground level.
So probably that programmer can be plugged in the parallel port
of a PC system.
It's a programmer who use a 9 volt DC from a wall block, the 9 volts
is used to supply a 555 who act as a voltage doubler to supply the
proper voltage to GAL during programming.
The 9 volt also go to a 7805 to supply the regulated 5 volts to all
of the IC's in the circuit. (expect the 555)
List of the IC's on the programmer:
QTY Part #.
1 7805
1 74LS373
3 16V8
1 RC555N
Unfortunatly, I don't get the user manual or any software to use with
that programmer, and I am not sure about the interface for it.
Any information about that would be appreciated, reply to my E-mail
address below...
Thank's
Jean-Pierre Bourdeau,
Courrier electronique (E-mail): bourdeau@dsuper.NOSPAM.net
Indicatif radio-amateur (Amateur radio callsign): VE2EXU
Page W3 (Web Page): http://oracle.dsuper.net/~bourdeau/
Courrier electronique via AMSAT (E-mail via AMSAT):
VE2EXU@AMSAT.nospam.ORG
Radio-amateur par paquets (Amateur radio packet):
VE2EXU@VE2CEV.#MTL.nospam.PQ.CAN.NOAM
Enlevez l'expression suivante lors de vos reponses par courrier
electronique;
(Remove the following sentence in your reply with E-mail): .nospam
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 7309In article: <5tfqsl$9b8$1@amdint2.amd.com> johna@dvorak.amd.com (John Archambeault) writes: > > Does anyone know how to instantiate the use of the flip-flops / buffers in the > unbonded pads in OrCAD? In a previous desgin I used verilog / synopsys to tell > XACT to use those flip-flops to instantiate a 100 bit FIFO. > This information may be out of date or wrong so go carefully but if you want what I think you want try looking for a symbol called UPAD or similar and use that instead of OPAD and as if you had the same design but also wanted to look at the resulting pad signal in the outside world. Logically, the fact that a pad does not have a bond wire on it makes absolutely no difference to the die its self so the logic of how to connect up a UPAD is identical to that applied to a normal pad and UPAD just tells the placement routines where to put the pad. hope this helps -- steve goodwinArticle: 7310
In article: <33fbfe2c.2011002@news.dial.pipex.com> terry.harris@dial.pipex.com (Terry Harris) writes: > > jim granville <Jim.Granville@xtra.co.nz> wrote: > > > Lattice parts have a GRP (global routing pool) which can route any > signal anywhere but unfortunately with some undocumented limitations, > when you lock down pins and the fitter can't fit (which sounds like > the problem the previous poster was getting) it is because of these > GLB restrictions. Being undocumented it is pretty hard to know what to > do about it. > Any hints you could supply on what these limitations are or where they may be detailed would be greatfully received. I use some lattice parts in simple configurations and dont want to get burnt the moment I step over the threshold in trems of complexity. TIA -- steve goodwinArticle: 7311
Hello everyones,
I buy in an amateur radio flea market an "EPLD device
programmer for 16V8, 20V8 and 39V18".
These chips are in the PAL/GAL family.
The company who made that programmer is ROYAL Electronics, it's
written "Made in Canada" in the back, and the model mumber is EV6000.
In the top of the programmer we have a 24 pins ZIF socket, it's a one
device programming box.
I check the date code of the chips inside and it's in the mid 80's.
(1984-1986)
It's written on the PC board REA
1986
/---------\
And also the following sign < MPC >
\---------/
We have also a flat ribbon cable with a DB-25 male connector on that
programmer.
I check for the various signals at the programmer side:
Pins 2 to 9 are connected to a 74LS373 at the various inputs of that
multiple D flip-flop chip.
Pin 12 is connected to a 16V8 Gal chip pin 14.
Pins 20 to 25 are at the ground level.
So probably that programmer can be plugged in the parallel port
of a PC system.
It's a programmer who use a 9 volt DC from a wall block, the 9 volts
is used to supply a 555 who act as a voltage doubler to supply the
proper voltage to GAL during programming.
The 9 volt also go to a 7805 to supply the regulated 5 volts to all
of the IC's in the circuit. (expect the 555)
List of the IC's on the programmer:
QTY Part #.
1 7805
1 74LS373
3 16V8
1 RC555N
Unfortunatly, I don't get the user manual or any software to use with
that programmer, and I am not sure about the interface for it.
Any information about that would be appreciated, reply to my E-mail
address below...
Thank's
Jean-Pierre Bourdeau,
Courrier electronique (E-mail): bourdeau@dsuper.NOSPAM.net
Indicatif radio-amateur (Amateur radio callsign): VE2EXU
Page W3 (Web Page): http://oracle.dsuper.net/~bourdeau/
Courrier electronique via AMSAT (E-mail via AMSAT):
VE2EXU@AMSAT.nospam.ORG
Radio-amateur par paquets (Amateur radio packet):
VE2EXU@VE2CEV.#MTL.nospam.PQ.CAN.NOAM
Enlevez l'expression suivante lors de vos reponses par courrier
electronique;
(Remove the following sentence in your reply with E-mail): .nospam
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 7312Tim Conway <timc@primafacie.com> wrote in article <33F493D6.25FB@primafacie.com>... > We are considering the use of ISP CPLD's. Anyone have any amusing > or helpful anecdotes regarding their use? > Thanks much. > -- > Tim Conway > Prima Facie, Inc. > (314) 989-0644 ext. 16 > (314) 989-0654 Fax > In my previous employment, we used ISP devices (Lattice, Altera (9K&7K), and Vantis Mach465). The goal was always to get to the lab and fail fast. Meaning find your problems early and correct them for the next spin of the PCB. ISP parts made this palatable. Some of the engineers could get 4-5 design spins a day when design iterations were needed. Now that the overall designs were failing faster and getting back into layout faster, it created a new bottleneck, PCB Layout! Fitting with locked pins occasionally required hours/days with the fitter/router, but I don't recall ever having to relax pin constraints and add wires to the PCB unless new inputs or outputs were required. One really needs to understand the underlying CPLD architecture well in order to be successfull, a little elbow grease and patience helps as well. It got to the point where I was afraid of OR gates in my equations, with all the PT neighbor eating et al. With a good simulation base for designs a lot of these problems become a mute point. It's been my experience that with the re-assurance of ISP parts on the board, designers are a lot sloppier with there initial designs, which in turn means more design iterations. Simulate, Simulate, Simulate. Management started pushing designs into layout with designs 50% complete and no simulation on a regular basis arguing that with ISP the risk was minimal. If managed properly ISP is a good thing, but when managed improperly it can be a disaster. As a designer I don't want to have to spend days or weeks fitting and routing a part to fix problems in the lab. Better yet I don't want to find any problems in the lab! Simulate, Simulate, Simulate. I suppose that it's only fair to add that I've left my previous employer to become the local Actel FAE. I'll skip the Actel sales pitch, but ask all to think twice about the true cost of ISP.Article: 7313
hi there all,
Is there any-one out there who is aware of
xlinx equilvent parts for the following ttl distrete parts for
use in an fpga design ..
shift registers as listed below
54xx595
54xx597
or fifo 16x4
i was considering using vhdl , but the code for these parts
escapes me to date.
if anyone who can help please let me know
thanks davey.
Article: 7314Michael David Scott (qwerty@WPI.EDU) wrote: e: I have compiled a file in synopsys (.vhd) and saved it as a .edf file. : I pulled this into Maxplus II and compiled the logic into a .vho file : for the component I want to use. Now, I want to use this .vho file to : perform simulations in Mentor Graphics qhsim with all the timing info the : file contains. : : Problem is, when I create the .vho file- all bus names are changed from the : format bus_name(x DOWNTO y) to bus_name_1_a, bus_name_2_a....... : This makes life a bit complicated when attempting to run my test bench. : It is possible to instatiate a new file on top of my original .vhd code : (ex. bus_1_a => bus(1) ......) : :but I'd perfer something like click the button in this window : to keep original names. : : : Thanks, : Mike Scott : : PS- In addition to a usenet response, an email would be greatly appreciated. : :Article: 7315
spp@bob.eecs.berkeley.edu wrote in article <5tl3ot$o5m$1@samba.rahul.net>... > But it remains unreasonable for a CAD tool to overwrite the > designer's input files. It should put its output somewhere else. > > Steve Agreed. -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 7316
Jim, The compliance testing I am aware of was in March, and this chip/revision (21152-AA) was not at this 'Plug-Fest'. I don't know about the one in July..... If you kept records as to which DEC bridge chips/revisions you actually tested with, I would be interested to see if one of them was the 21152-AA. I pass all simulations (back annotated timing and 'massaged' with model_io), with 7ns setup and 0ns hold. The design works correctly with any other bridge, and in any system, but ones with the 21152-AA bridge chips. The issue is definately the hold time, as slowing down the clock frequency does not affect the failure mode. Since all the PCI signals are registered in the IOB, except FRAME, there should be no timing problem at all if the chip truely does meet the 0ns hold time spec. And FRAME is timed such that that it, too, should have no problem with the 0ns hold time. Please e-mail me with the 'Plug-Fest' bridge info if you would. Thanks, Austin Jim McManus <jim.mcmanus@xilinx.com> wrote in article <34005A11.BF52A840@xilinx.com>... > Austin, we have a customer who has passed the PCI-SIG Compliance Workshop > last July; this included working behind DEC bridges. So far, it's always been a > software issue when devices using our LogiCORE PCI macro don't work behind a > bridge. We have not seen any issues between our macro and PCI-PCI bridges. > However, if you are seeing a problem with our macro, contact me directly, and > I'll > work to resolve it. > > I'm glad you found some info about using the model_io perl script. If you would > like a copy of the documentation that describes this, it's available on-line in > the > v1.1 User's Guide at: > http://www.xilinx.com/products/logicore/pci/pcilit.htm > > > Jim McManus > Xilinx PCI Applications Engineer > > > Austin Franklin wrote: > > > I finally found someone at Xilinx who 'explained' what was going on in the > > simulations... > > > > He said that the timing numbers that are in the simulation file are > > 'extremely conservative' and they have a perl script that I have to run on > > the back annotated .xnf file to put in the 'databook' numbers. > > > > So, I ran this script, and now my simulation works fine....but the actual > > silicone still doesn't work behind a DEC bridge...and when we try to probe > > it...it works... > > > > So, next question is has anyone tested out their Xilinx PCI design behind a > > PCI bridge? > >Article: 7317
ANNOUNCEMENT:
MINC is now offering a full-featured VHDL synthesis engine for $495.
VHDL EASY(tm) is VHDL-93 and IEEE 1076 compliant and uses a combination
of
proprietary and industry standardsynthesis and optimization
methodologies
including:
* Macro inference and expansion * BDD and ROBDD optimization
* Resource sharing * Lexigraphical factorization
* State machine extraction * Boolean Matching
VHDL EASY also includes your choice of one target device library:
* AMD/Vantis MACH 1-4 * AMD/Vantis MACH 5
* Altera 7000/9000 * Actel 1/2/3
* Lattice ispLSI 1/2/3 * More coming
For more information, please see our website at http://www.minc.com,
or email us vhdleasy@minc.com.
*** This notice attempts to meet the standards set forth for friendly
usenet notices and advertising by Joel K. Furr in
news.announce.newusers.
For more information, see http://www.danger.com/advo.html.
Article: 7318In comp.lang.vhdl Kevin Bush <kevin.bush@minc.com> wrote: : ANNOUNCEMENT: : MINC is now offering a full-featured VHDL synthesis engine for $495. : VHDL EASY(tm) is VHDL-93 and IEEE 1076 compliant and uses a combination : of : proprietary and industry standardsynthesis and optimization : methodologies : including: Is it available for Linux? -- Uwe Bonnes bon@elektron.ikp.physik.th-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 7319
Have you seen the following book published by Newnes? I would be glad of feedback for new editions and so on. Please message Matthew.Deans@bh.com with comments. Duncan Enright FPGAs and Programmable LSI A Designer's Handbook Geoff Bostock * How to design using latest techniques and technology * Practical hands-on guide This is the most comprehensive practical guide to designing with field programmable gate arrays (FPGAs) and programmable LSI. Programmable logic devices (PLDs) have been in general use for over twenty years. The demands of modern electronic design mean that traditional PAL technology has given way to a powerful new approach: FPGA technology. The design process for an FPGA needs to be far more rigorous than for PAL since troubleshooting is far harder to perform. There are, moreover, a dozen or more manufacturers of FPGAs, each with a different architecture and performance, so choosing the right device for any particular application is a critical part of the design process. Similarly there are various design methods, each with particular features. This book shows a designer how to choose the appropriate FPGA and design method for any application. It also gives hints and tips, based on the author's wide experience in the field, to allow designers to optimise performance of any particular family of devices. CONTENTS: Classic logic devices; Programmable LSI techniques; Designing FPGAs; Large PAL structures; RAM-based FPGAs; Antifuse FPGAs; Selecting and using FPGAs; FPGA application; Device manufacturers; CAD and programmer suppliers; References; Trade Marks; Index. READERSHIP: Electronics engineers, designers, technicians and students. 1996 240pp 234 x 156mm 125 line illustrations PAPERBACK 0 7506 2883 9Article: 7320
FPGA `98
Call for Papers
1998 Sixth ACM International Symposium on
Field-Programmable Gate Arrays
DoubleTree Hotel, Monterey, California
February 22-25, 1998
http://www.ece.nwu.edu/~hauck/fpga98
==========================================================
As Field-Programmable Gate Arrays become more essential to the design of
digital systems there is increased pressure to improve their performance,
density and automatic design. This symposium follows the largest ever
gathering of this kind last year in Monterey at FPGA `97. For FPGA `98,
we are once again soliciting submissions describing novel research and
development in one or more of the following (or similar related) areas
of interest:
FPGA architecture: logic block & routing architectures, I/O structures
and circuits, new commercial architectures.
CAD for FPGAs: placement, routing, logic optimization, technology
mapping, system level partitioning, testing and
verification.
Interactions: between CAD, architecture, applications, and
programming technology.
Fast prototyping: for System level design, Multi-Chip Modules.
Applications: use of FPGAs in novel circuits, as emulators and
compiled accelerators.
Field-programmable interconnect chips and devices (FPIC/FPID.)
FPGA-based compute engines.
Field-programmable analog arrays.
==========================================================
Authors should submit 20 copies of their paper (12 pages maximum) by
September 26, 1997. Notification of acceptance will be sent by December 1,
1997. The authors of the accepted papers will be required to submit the
final camera ready copy by December 15, 1997. A proceedings of the accepted
papers will be published by ACM, and included in the ACM/SIGDA CD-ROM
publications. All submissions should be sent to:
Sinan Kaptanoglu
FPGA `98
Actel Corporation
955 East Arques Avenue,
Sunnyvale, CA 94086 USA
e-mail:sinan@actel.com
phone: (408) 522-4319
fax: (408) 522-8041
==========================================================
General Chair: Jason Cong, UCLA,
Financial Chair: Carl Ebeling, U. of Washington,
Program Chair: Sinan Kaptanoglu, Actel,
Publicity Chair: Scott Hauck, Northwestern U.
============================
Technical Program Committee:
============================
Michael Butts, Quickturn
Jason Cong, UCLA
Eugene Ding, Lucent
Carl Ebeling, U. of Washington
Scott Hauck, Northwestern U.
Dwight Hill, Synopsys
Brad Hutchings, BYU
Sinan Kaptanoglu, Actel
David Lewis, U. of Toronto
Fabrizio Lombardi, Texas A&M
Jonathan Rose, U. of Toronto
Rob Rutenbar, CMU
Malgorzata Marek-Sadowska, UCSB
Gabriele Saucier, IMAG
Martine Schlag, UCSC
Tim Southgate, Altera
Steve Trimberger, Xilinx
John Wawrzynek, UCB
Martin Wong, UT at Austin
============================================================================
Sponsored by ACM SIGDA, with support from Actel, Xilinx, Altera, and Lucent.
============================================================================
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 7321Richard Iachetta wrote: > spp@bob.eecs.berkeley.edu wrote in article > <5tl3ot$o5m$1@samba.rahul.net>... > > > But it remains unreasonable for a CAD tool to overwrite the > > designer's input files. It should put its output somewhere else. > > > > Steve > > Agreed. > > -- > Rich Iachetta > IBM Corporation > iachetta@us.ibm.com I believe it's about time that Altera comes up with some proper version/revision control functionality, instead of this manual hocus-pocus with .acf files. In this area, they could learn a lot from Xilinx and its M1 tool. I guess we have to wait for Maxplus3? Regards, Jaap Mol. P.S. Our company use both Altera and Xilinx, and I'm not a Xilinx employee....Article: 7322
In article <3401EA0A.3F9A@minc.com>, Kevin Bush <kevin.bush@minc.com> wrote: >ANNOUNCEMENT: > >MINC is now offering a full-featured VHDL synthesis engine for $495. >VHDL EASY(tm) is VHDL-93 and IEEE 1076 compliant and uses a combination >of >proprietary and industry standardsynthesis and optimization >methodologies But is it available for Linux? philArticle: 7323
ptkwt@kelly.teleport.com (Phil Ptkwt Kristin) writes: >In article <3401EA0A.3F9A@minc.com>, Kevin Bush <kevin.bush@minc.com> wrote: >>ANNOUNCEMENT: >> >>MINC is now offering a full-featured VHDL synthesis engine for $495. >>VHDL EASY(tm) is VHDL-93 and IEEE 1076 compliant and uses a combination >>of >>proprietary and industry standardsynthesis and optimization >>methodologies >But is it available for Linux? >phil In the short, no. In the long, there is code in VHDL EASY which is win32 specific (mostly the interface code). We've got several methods under consideration for making it portable, but unless we see some kind of significant demand for a OS portable version, then we can't afford to spend (much) effort on it. I'm sure that if someone were able to get together a group of names of people who would be willing to spend actual $$$ for several hundred copies, and then email them to Kevin, the word would come down PDQ. Todd Walk walk@mrcnext.cso.uiuc.edu toddw@minc.comArticle: 7324
In article <5tvir6$10j$1@vixen.cso.uiuc.edu>, Todd Walk <walk@mrcnext.cso.uiuc.edu> wrote: >ptkwt@kelly.teleport.com (Phil Ptkwt Kristin) writes: > >>In article <3401EA0A.3F9A@minc.com>, Kevin Bush <kevin.bush@minc.com> wrote: >>>ANNOUNCEMENT: >>> >>>MINC is now offering a full-featured VHDL synthesis engine for $495. >>>VHDL EASY(tm) is VHDL-93 and IEEE 1076 compliant and uses a combination >>>of >>>proprietary and industry standardsynthesis and optimization >>>methodologies > >>But is it available for Linux? > >>phil > >In the short, no. [excuses snipped] Has anyone ever tried to take a poll of the number of VHDL developers craving for Linux development tools? Perhaps now would be a good time to start. VHDL development tools are the single reason I still have windows on the machine. I currently use Altera's stuff, but would switch in the blink of an eye if even a half decent set of tools are made available for Linux. Altera supports a half-dozen unix's already but seems to be blind to the growing number Linux users. This seems to be something they share with everybody in the field. Any ideas on enlightening developers welcome. If I'm merely delusional and there really are very few Linux-using VHDL developers out there, feel free to enlighten me! mike just my 2c
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