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
Anyone know of a conversion utility that will allow a .pds file (either PldShell or MachXL flavour) to be used in the Max environment ? (want to migrate a MACH design to an Altera 8000 device) cheers MikeArticle: 3451
Furio Pettarin <pettarin@elettra.trieste.it> wrote: >Hi, >I'm a new Xilinx user. >I work with Xact 6.0.0 and OrCAD 386+. >Are there other Xilinx - OrCAD users? >Thank you. Yes. I have Xact 6, though I use 5.1. OrCAD 386+ too. I run them both in DOS. Works fine for my XC4000 designs. What do you want to know? _________________________________________________________ Kirk Hobart Santa Barbara, California hobart@rain.orgArticle: 3452
Dear Friends, I am using Exemplar's Galileo Logic Explorer v.3.22. My question is that I can not find any synthesis command to specify fanout limit for individual net (and input pin) of the to-be-synthesized VHDL entity. Some nets are critical but some nets are not, for example the reset signal to all Flip-flops needs much less buffers. The only related command I can find in the user's guide is -max_load. But it is global significant. I can not get what I want with it. Could any one out there with related ecperience can help me? Best wishes, Felix K.C. CHEN -- --------------------------------- Felix, Kuan-chih CHEN (³¯ «a §Ó) Associate Project Manager System Product Division D-Link Co., Hsin-chu, Taiwan Email: flxchen@diig.dlink.com.tw Machines and tools are only as good as the people who use it. ---------------------------------Article: 3453
Mike Diack wrote: > > Anyone know of a conversion utility that will allow a .pds file > (either PldShell or MachXL flavour) to be used in the Max environment ? > (want to migrate a MACH design to an Altera 8000 device) > cheers > Mike I converted a Pldshell .PDS to the MaxPlus2 format. It made a mess out of it, but it showed me what I had to do to make it work. I think the converter was on the CD that MaxPlus2 comes on. I don't remember what it was called, but there was a section in the doc I printed out called "conversions" or something like that. -- Jeff Sampson jeffs39@skypoint.com Minneapolis, MN, USAArticle: 3454
>>>>> Don Husby <husby@fnal.gov> writes: > I've been using Viewdraw-Office now for a couple of weeks and > have the following humble opinion: They've added more rough edges > and taken away some really useful stuff... Our maintenance contract covered free upgrades to Workview Office, so we purchased copies of Windows 95 for our workstations and installed the new software. We were distinctly unimpressed with the results. Between Workview Office's elimination of important features -- command-line entry, macros, and so on -- and Win95's poor stability and lousy support for DOS applications, we figured that it was a step backwards. For the meantime, anyway, we've gone back to ProSeries 6.1 under OS/2. Perhaps we'll try Workview Office again (under NT?) when it *really* gets out of beta. -- Roger Williams finger me for my PGP public key Coelacanth Engineering consulting & turnkey product development Middleborough, MA wireless * DSP-based instrumentation * ATE tel +1 508 947-8049 * fax +1 508 947-9118 * http://www.coelacanth.com/Article: 3455
Free Registration for First Online Conference Begins PLDCon'96 Xtension - http://www.pldsite.com/ext Registration is now open for the EE Times' PLDCon '96 Xtension, a pioneering venture into online conferencing. All segments of the event take place online through your Web browser - beginning with registration. And you can register at no charge! PLDCon '96 Xtension stretches the "live" Boston and Dallas meetings to engineers worldwide, bringing you three core tutorial sessions over the Web. The program begins June 10 and will continue for 8 weeks. You can participate from work, home, or on the road -wherever there's access to the Web. But you must be registered to engage in the conference sessions. The Xtension is composed of three 8-week tutorial sessions: * ASIC Emulation and Rapid Prototyping (chairman: Wolfgang Hoflich, applications manager, Aptix) * Using HDLs for FPGAs & CPLDs (chairman: John Birkner, vice president CAE, QuickLogic) * Optimizing Designs in Large Programmable Devices (chairman: Mike Dini, president, The DINI Group) Attend at your own pace, on your own schedule, studying the topics and discussing the materials with other participants and with the session chairmen throughout the 8-week run of the conference. Each session has a rich library of references, including presentations from the PLDCon '96 meetings. A unique new messaging system is built in that allows the chairman to personally guide the session efficiently, according to the interests of the participants. By the end, each participant will have collected a complete proceedings of the discussions and copies of the study materials in their own computers. Space is limited to 100 per session. Register now! For free PLDCon'96 Xtension registration and more details, access http://www.pldsite.com/ext. Cordially, Stan Baker Program ChairmanArticle: 3456
UNIX/Windows OS war comments follow; skip if uninterested! John Cooley quotes: Elliot Berger: > When will EDA providers finally realize PC platform support (Windows NT, in > particular) actually provides *more value* to users than UNIX support? Yuck. I've had to fight daily with Windows and will be glad to see the last of it. EDA tools I've seen under Windows so far have been toys, just like the OS. Abbie Kendall, OrCAD: > When are Mentor, Cadence and Synopsys going to deliver Windows products? Good question. While Windows seems to work OK for PCB design, all IC designers I've ever talked to greatly prefer UNIX. I simply don't see the market for Windows versions of those programs. The PC vendors (OrCAD, Protel, etc.) deliver cheap, low-functionality programs that are simply unsuitable for serious IC work. Mentor et al. deliver very expensive software, but SW that one can generally get to work for mission-critical IC designs. They're two different markets. Tom Mayo, General Electric: > Have you given > any thought to targetting low-cost PC-based Unix operating systems, > especially Linux? Linux is a solution that many people are using to > supplement Sun and HP workstations using lower cost PCs. Michael Dantzer-Sorensen: > When are the EDA vending companies going to support PC's running > some kind of UNIX like Linux or SCO or something else?? Now we're talking! Microsoft isn't even at DAC, so I don't think they have much of an interest in ECAD. The last thing I need in my work is a crippled OS to hobble productivity. -- David F. SkollArticle: 3457
Peter wrote: > I can make it reliably configure with either of: > > 1. the 3030's CCLK output driving the 32-off 3064s direct, with 220pF > to GND; > > 2. the 3030's CCLK output driving a 74AC244 buffer, then 470pF to GND, > then to the 3064s. > > I also find that with a very clean but slow edge it does not > configure, around 30ns or slower. > > Any resistor in series makes things worse. > > The only conclusions I can reach are: that I had transmission line > problems; that the edge must be faster than about 30ns; that the > devices are sensitive to noise or glitches which are too fast to see > on a 250MHz scope. Here's my guess: There's a setup/hold time in the configuration data and CCCLK "system". Slow edge rates mean that different receivers (i.e. slave FPGAs) with slightly different logic thresholds are developing excessive clock skew amongst themselves, and the data valid time of the configuration data stream broadcast amongst the lot isn't adequate. Hence a clean but slow edge won't solve the problem. Again, this is a guess. The 2nd solution listed above involves delaying the clock with respect to the master FPGA's data output, and that may push the system into a more reliable operating region. Anyone from the X company care to comment? Anyone else? An experiment to try: Vary the clock delay through buffering circuitry without any capacitors to slow the edge rate. See if there are any siginificant differences. Try the same series again, with the CCLK inverted. Then run the same 2 series again, but delay the config data instead of the clock (essentially advancing the CCLK with respect to the data). If there is no pattern, that suggests that perhaps data <--> CCLK timing between the master and the slaves is NOT the primary issue. If there *is* a pattern, then you've learned something as well. ************************************************************************** Bob Elkind email:eteam@aracnet.com CIS:72022,21 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ******** Video processing, R&D, ASIC, FPGA design consulting *************Article: 3458
Does anybody know any standard way the RS422/RS485 signals are mapped in DB-9 or 8-pin phone jack (or any other connector)? Is there such a thing as CTS/RTS signals for RS422/RS485? How are these signals mapped? Kalyan Gokhale kgokhale@execpc.comArticle: 3459
Kalyan Gokhale wrote: > > Does anybody know any standard way the RS422/RS485 signals are mapped > in DB-9 or 8-pin phone jack (or any other connector)? Is there such a > thing as CTS/RTS signals for RS422/RS485? How are these signals > mapped? > > Kalyan Gokhale > kgokhale@execpc.com There are two standards for 422/485 pinouts. One is EIA 449 (37 pin), the other is ANSI/TIA/EIA-530-A (25 pin). Yes CTS/RTS are supported.Article: 3460
tobias@nord.eunet.no wrote: > > Hello, > > When I called the xilinx dealers here in Norway, they told me I needed > a hardware programmer that costed 1700 dollars just to program the > xilinx chips. Arent there any cheaper way to programm this chips (make > an own programer) ??? > > Is there any FAQ about FPGAs availible ?? If you are interested in the SRAM based FPGA's, no programmer is required at all. You can configure the devices from the parallel port of your PC and they will remain programmed for a long as power is applied. The current DigiKey catalog (www.digikey.com) shows a low cost Xilinx programmer ($300 + adapters) from Deus Ex Machina that handles the 7xxx series EPROM based CPLDs and the serial configuration PROMs for the SRAM based families. Unless you already have Xilinx software, you will have to spend some money there. The entry level toolset for SRAM devices runs around $1000. The entry level toolset for CPLD devices is less than $100 (I think). Regards, ScottArticle: 3461
In article <4ouobg$3hv@Slava.nord.eunet.no>, tobias@nord.eunet.no wrote: > When I called the xilinx dealers here in Norway, they told me I needed > a hardware programmer that costed 1700 dollars just to program the > xilinx chips. You do not need any hardware programmer for SRAM-based Xilinx FPGAs. Xilinx also makes CPLDs which must be programmed in a hardware programmer, although the newest family, XC95000, can be programmed on the pc-board, without the need for a hardware programmer. I suggest you contact BIT Elektronikk 1364 Hvalstad, tel: 02-98-13-70 they can send you a data book, and inform you about devices and development software. Peter Alfke, Xilinx ApplicationsArticle: 3462
Kirk Hobart wrote:
>
> Furio Pettarin <pettarin@elettra.trieste.it> wrote:
> >Hi,
> >I'm a new Xilinx user.
> >I work with Xact 6.0.0 and OrCAD 386+.
> >Are there other Xilinx - OrCAD users?
> >Thank you.
>
> Yes. I have Xact 6, though I use 5.1. OrCAD 386+ too. I run them both
> in DOS. Works fine for my XC4000 designs. What do you want to know?
> _________________________________________________________
> Kirk Hobart Santa Barbara, California hobart@rain.org
Hi Kirk,
thank you for your answer.
My problem concerns the use of the OHDL language.
I wrote an OHDL source file in which I explicitly assigned the pin to
each signal. I compiled the source (obtaining the *.PLA file) and then
I fitted the compiled file (in a XC3130pc84-3)using the Xilinx fitter.
I obtained the Xilinx netlist (*.XNF file).
Then I entered Xact. The translate step (XMAKE) finished regularly, but
the program XNFPREP Version 5.2.0 gave me the follwing error:
XNFPREP: ERROR 4007:
Everything in the design was deleted. This was probably caused by a
number of key signals being sourceless or loadless. See the Logic
Trimming Summary section below for details.
It seems that the information on the pin locations was lost during the
process!
Then my question is: how have I to specify correctly the pin locations in
the OHDL source code?
There is another important matter.
When I describe an FPGA with SDT 386+ using the Xilinx libraries there
are a lot of attributes that I can place on symbols or nets, e.g. the
attribute FAST that set a high slew rate in an output buffer or in an
output pad. The pin assignment is actually the attribute LOC. The
attribute X makes a net mapped outside the logic blocks.
How can I place these and all other attributes inside the OHDL source?
Furio Pettarin
Sincrotrone Trieste
Italy
http://www.elettra.trieste.it
Article: 3463In article <31B1BB13.2AAD@aracnet.com>, eteam@aracnet.com wrote: > Here's my guess: There's a setup/hold time in the configuration data > and CCCLK "system". Slow edge rates mean that different receivers > (i.e. slave FPGAs) with slightly different logic thresholds are > developing excessive clock skew amongst themselves, and the data valid > time of the configuration data stream broadcast amongst the lot isn't > adequate. Hence a clean but slow edge won't solve the problem. > > Again, this is a guess. > > The 2nd solution listed above involves delaying the clock with respect > to the master FPGA's data output, and that may push the system into a > more reliable operating region. > > Anyone from the X company care to comment? Anyone else? Here comes the other Peter ( Peter Alfke from X-company) I am not happy that this still remains a mystery, although it seems to be fixed. There's an XC3030 configured in peripheral mode, it drives 32 slaves, but these are all in parallel, since their internal configurations are identical. Bob, you have been very helpful in other cases, but let me contradict you here: I am sure that clock or data skew is not an issue. ( Hickups yes, skew no ). CCLK is generated inside the XC3030 and drives its CCLK output. That same pin also happens to act as the CCLK input to the logic inside the XC3030, so any strange hick-up on that output pin can also affect the internal use of CCLK in the XC3030. ( I hope I am clear here, it's not obvious, it's usually not important, but understanding this might sometimes help debugging ) The XC3030 is the CCLK and data spource for the remaining 32 devices, all hooked up in parallel. As we all know, DOUT changes as a result of the falling CCLK edge, but the receiving devices clock data in on the rising CCLK edge. That means that the interface should tolerate enormous data and clock skew. CCLK is most likely >500 ns per half-period, but DOUT is delayed max 100 ns after the falling edge, and DIN must be valid 60 ns before the following rising edge. 500 - 100 - 60 = 340 ns are available as "slob". So skew or differential delays should not matter. For a moment, I thought what terrible thing would happen if the buffer were inverting CCLK, but the '244 is a non-inverting buffer. I understand that the 32 clock and data inputs are somewhat of a star connection, which makes it almost like a lumped capacitive load ( as opposed to a long string, which would behave more like a transmission line ). Slowing down CCLK such that the rise and fall times are longer than the round-trip transmission-line delay should be easy, and that's what Peter apparently did to cure the problem. Observing the appearance of the 40 preamble data bits on DOUT of all 33 devices is an excellent check for data and clocking integrity. I cannot emhasize that enough. That's all from me. Peter Alfke, Xilinx Applications.Article: 3464
In article <31ad87b8.16410546@news.dial.pipex.com>, ft63@dial.pipex.com (Peter) writes: > > >My guess is still that there are double-transitions (reflections) on CCLK. > >That's why I suggest to lengthen the transition times drastically, e.g > >with a 50 Ohm series resistor and a 200 pF capacitor to ground, the usual > >dirty remedy when s signal causes reflections. This is out to lunch from a signal integrity point of view! Multiple reflections from more than one load separated by significant trace length are never helped by lengthening the line. A 50ohm/200pF RC yields such a slow rise time that transmission line effects go away unless the total length is huge. Instead, it increases the noise susceptibility at _all_ receiving circuits. > This is probably what it was. I say "probably" because I can make it > fail even when the waveform looks clean, on my 250MHz scope. > > I can make it reliably configure with either of: > > 1. the 3030's CCLK output driving the 32-off 3064s direct, with 220pF > to GND; > > 2. the 3030's CCLK output driving a 74AC244 buffer, then 470pF to GND, > then to the 3064s. > > I also find that with a very clean but slow edge it does not > configure, around 30ns or slower. > > Any resistor in series makes things worse. > > The only conclusions I can reach are: that I had transmission line > problems; that the edge must be faster than about 30ns; that the > devices are sensitive to noise or glitches which are too fast to see > on a 250MHz scope. Were it a transmission line problem of the reflection sort it would be scopable, and series termination would damp the reflection, helping, not hurting the situation. If you have a long signal line with a receiver in the middle however, a series terminator would induce a step function where the intermediate receivers hang somewhere between logic high and low until the reflection returns from the end of the line, leaving a susceptibiltiy window while it waits. With a heavy RC and a very long rise time you end up with all receivers being susceptible to "clock on noise" as the signal slowly ambles by the threshold points. This may be a factor with 30ns+ rise times. A pure reflection problem would not occur with a 30ns rise time unless the clock trace were several _meters_ long. It sounds very much like a critical timing issue that you are skewing with capacitive delays- a very un-reliable method to be sure. Loading a signal with 220-470pf is effectively short circuiting the driver for the transitions, which can have other, unintended consequences (like creating internal glitches on the driving device as rails on the die sag, lowering effective thresholds!) Loads greater than 50pf are generally outside of the guaranteed operating range of anything other than heavy bus drivers (hence the 244s?). > > >I hate to make this sound complicated, it really is not. And we will fix > >this design, if we only get all the information. > > Short of posting the schematic and PCB layout, I did describe it as > best as I could. But it is working now, so - I'd be reluctant to call it "working" until you understand what's been affected. >From your description I'd say you made the symptom go away for now, on this unit, at this temperature, this phase of the moon... Don't go to production with this "fix" if you can help it! $0.02 from an RF/transmission line guy caught lurking here whose knowledge of VHDL extends only to the correct spelling. dana dd@chrysal.com ********************************************************************************* Papillon Research Corporation | (formerly Chrysalis Research Corp.) | FCC problems are no accident- 52 Domino Drive | they're either designed in or Concord, MA 01742-2817 | or designed out! (508) 371-9115 fax 371-9175 | info@chrysal.com | *********************************************************************************Article: 3465
This thread is interesting, I have some experience with Synopsys, but work mostly with ASYL+ (from IST Grenoble.fr). When I worked with Synopsys I didn't look at the state encoding stuff, so I learned something new now.. But ASYL+ offers several state encoding options (one hot,optimized compact, Gray, Johnson, sequential, random) where things like long paths and succesive code is regarded, you can also choose the type of flip-flop - well you can also leave it to the synthesizer..(like most the time :) The manual says, if you want to have real one hot encoding then use an enumerated type for the states and leave the encoding to the synthesizer. If you encode your states yourself, like S1 : bit_vector(0 to 3) := "0001"; then the synthesizer will identify it with "ST(3) and not ST(2) and not ST(1) and not ST(0)" instead of just "ST(3)". I think thats what Andrew Hana regarded as non one hot encoding.. It's interessting, how one can use a nice feature without thinking about, how nice it is.. Thomas -- ------------------------------------------------------------------- | Thomas Hadlich hadlich@infaut.et.uni-magdeburg.de | | http://infaut.et.uni-magdeburg.de/~hadlich | -------------------------------------------------------------------Article: 3466
Hello, I am quite new to this FPGA buisness, Have only worked a little bit with gals. Now I want to start to learn about FPGAs for some hobby project. When I called the xilinx dealers here in Norway, they told me I needed a hardware programmer that costed 1700 dollars just to program the xilinx chips. Arent there any cheaper way to programm this chips (make an own programer) ??? Is there any FAQ about FPGAs availible ?? regards, tobiasArticle: 3467
I had the same question a while back. I did finally get a document from National Instruments regarding RS-485. The best I have been able to find for 422 is second-hand information about a MAC printer port. Here is the information I have. If anyone has better, I would also be interested. PIN RS-232 RS-485 RS-422(Mac Printer?) 1 DCD GND Frame GND 2 RXD CTS+(HSI+) +5 3 TXD RTS+(HSO+) Sig GND 4 DTR RXD+ TXD+ 5 GND RXD- TXD- 6 DSR CTS-(HSI-) +12 7 RTS RTS-(HSO-) Handshake 8 CTS TXD+ RXD+ 9 RI TDX- RXD- I'm not sure whether you are using 2-wire or 4-wire 485, or for what purpose. (And yes there are both 2 and 4-wire version of 485 despite the fact that most people think of 4-wire as 422.) 485 is typically used for 1) longer serial runs, and 2) multi-dropped communications. If you are using the latter, the RTS/CTS terms are usually made unnecessary by a good protocol design. Could probably help more if I knew more details. -FunArticle: 3468
EDA Research is polling the ASIC design community on ASIC design practices across a wide-range of applications. The results will be publically posted (not sold) July 1, 1996 on the Web. To encourage participation, a prize drawing will be held for all participants (see Web page). To find the ASIC survey, point to http://eda.mdc.net/ I hope you can participate. We are trying to determine the "State-of-the-Art" in ASIC design today. EDA ResearchArticle: 3469
In article <31B2E619.195F@sound.net>, Mark Fanara <mfanara@sound.net> wrote: >Kalyan Gokhale wrote: >> Does anybody know any standard way the RS422/RS485 signals are mapped >> in DB-9 or 8-pin phone jack (or any other connector)? Is there such a >> thing as CTS/RTS signals for RS422/RS485? How are these signals >> mapped? >There are two standards for 422/485 pinouts. One is EIA 449 (37 pin), >the other is ANSI/TIA/EIA-530-A (25 pin). Yes CTS/RTS are supported. These two standards are not completely balanced, and the RTS/CTS is run on RS232 singled ended drivers and receivers. There are other standards using RS422. None of these use RS485, which is a different kettle of fish again, with a different purpose, even if it uses similar drive and loading characteristics. For RS422, consider also X.21. The full implementation of X.21 is quite complex, but partial implementations are widely used in parts of the world. The standard connector forit is a DB15. There is no equivalent CTS pin(s). Arnim. -- Arnim Littek arnim@actrix.gen.nz Actrix Networks Ltd. fax +64-4-499-1130 uucp/PPP/SLIP/BBS accounts tel +64-4-499-1122Article: 3470
>It sounds very much like a critical timing issue that you are skewing with >capacitive delays- a very un-reliable method to be sure. Loading a signal with >220-470pf is effectively short circuiting the driver for the transitions.. I agree with your general comment, in that hanging caps like this around a circuit is a bodge (USA: "kludge"). But I had to achieve a happy medium between a fast edge (say <10ns) which causes problems with reflections, and a slow edge (say >30ns) which is apparently too slow for the devices being driven with it. In the end I actually used a 10R resistor on the 74AC244 output, then a 440pF to GND. The 10R was put in simply because I had a position on the PCB for a series resistor network for this and other signals (in case some "slowing down" was needed) and leaving this in looks better visually than wiring it all across. I was happy with the resulting waveform, and tested the system (with copious amounts of freezer spray) over a reasonable temperature range. >Don't go to production with this "fix" if you can help it! Fortunately, this product will never go into volume production. As a post-post-post mortem on this job, I think the best way to distribute CCLK around such a big board would be to distribute it over a slowly-driven net, and have locally placed 74HC14s (a schmitt) to buffer it for each (small) group of FPGAs. The odd thing is that for all the responses I have had here, not one is from someone who has put any significant number of FPGAs on one board. >$0.02 from an RF/transmission line guy caught lurking here whose knowledge of VHDL >extends only to the correct spelling. You're not the only one. I went on a VHDL course recently, and came out firmly decided to avoid it, mainly because there are so many ways to make very subtle errors. Peter.Article: 3471
>There are two standards for 422/485 pinouts. One is EIA 449 (37 pin), >the other is ANSI/TIA/EIA-530-A (25 pin). Yes CTS/RTS are supported. I work a lot with 422/485, and I think the only "standard" is the 37-way thing, which dates back many years. And it is pretty useless because a DB37 is huge. All the other "standards" are within one or another manufacturer's product range only. Peter.Article: 3472
Hi all, I am looking for companies which manufacture FPGAs based on the following technologies: E/EEPROM, Antifuse(Si-electrode) and Antifuse(Metal-electrode). I also appreciate the details about FPGA device families based on these technologies. With regards, -- -=---===---===--==-=--==--====-==-====-===-===--=-==---==--==-===-===-===-==-== Suthikshn Kumar Phone: 61-3-93449207(O) L2.34, Computer Engineering Group, Dept. of Elec and Electronic Engg, Fax : 61-3-93446678 The University of Melbourne, E-mail: skc@mullian.ee.mu.OZ.AU 221, Bouverie Street, VIC-3053 Australia http://www.ee.mu.OZ.AU/papers/info/seminar/Kumar.htmlArticle: 3473
fpga error occour?Article: 3474
******************************
SUBMISSION DEADLINE EXTENDED
TO JUNE 30, 1996
******************************
CALL FOR PAPERS
INTEGRATED COMPUTER-AIDED ENGINEERING
(A Wiley-Interscience Journal)
SPECIAL ISSUE: LOW POWER ELECTRONIC SYSTEMS
(http://www.ece.arizona.edu/ece/csdl/icae)
Improved techniques for computer-aided design of low power electronic
systems has become critical to fields such as mobile computing and
communications. Low power design requires advances and integration
of many interdisciplinary fields and topics including digital and analog
VLSI design, modeling and simulation of interconnects, thermal management,
design within noise margins, power management, materials science, design
of single and multi-chip implementations, mixed-signal design design
optimization, etc. Papers are sought for this special issue which
describe innovative techniques in computer-aided engineering and
integration of computer technologies for solving related engineering
problems. In addition, novel industrial applications of CAE to low power
design are welcomed. In particular, papers that incorporate
neurocomputing, genetic algorithms, fuzzy logic, intelligent and adaptive
systems, distributed or parallel processing and/or other emerging
computer technologies are encouraged.
Integrated Computer-Aided Engineering} is a prestigious, peer-reviewed,
interdisciplinary journal that publishes original research papers and
novel industrial applications that integrate leading-edge and emerging
computer technologies for solving complex engineering problems.
SUBMISSION:
Submitted manuscripts must be typed double-spaced and include an
abstract of no more than 100 words. Please submit five copies of the
complete paper including an original and one copy of camera-ready
illustrations by June 30, 1996 to:
Jo Dale Carothers
Guest Editor, Integrated Computer-Aided Engineering
Dept. of Electrical and Computer Engineering
The University of Arizona
Tucson, AZ 85721
Telephone: 520/621-8733
FAX: 520/621-8076
email: carothers@ece.arizona.edu
All submissions must be accompanied by a cover letter indicating the
name, address, telephone number, and FAX number for the corresponding
author. Authors should obtain company and government clearances prior
to submission of papers. No paper can be published unless it is
accompanied by a signed publication agreement. A copy of the agreement
appears in most issues of the journal.
Submission of a manuscript implies that it is the author's original
unpublished work and is not being considered for publication in another
source. Further information on formats also appears in the journal.
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