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
We are considering implementing asynchronous circuits using FPGAs. We need to choose FPGAs such that hazard-free logic can be realized and the FPGAs can be reprogrammable in circuits. The following are in-circuit reprogrammable FPGAs we know right now: Company Family WWW ========== ============ ========================================== Xilinx LCA Plessey ERA AMD Atmel CLi AT&T Orca Altera Flex,UTFPGA1 http:\\www.altera.com Toshiba Algotronix CAL,Triptych ========== ============ ========================================== Question 1. Which of them are (seem to be) suitful for asynchronous circuits? Question 2. Do you know any other products may be suitful for asynchronous circuits? Question 3. Any experience or suggestion in implementing asynchronous circuits with FPGAs are welcomed. Question 4. Any Email-address, WWW, or tel. no. related to the above products are welcomed. Thanks a lot in advance. -John Email: cheng@cs.columbia.eduArticle: 776
In Article <3ijrn8$c54@src-news.pa.dec.com> murray@src.dec.com (Hal Murray) writes: >In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes: > >|> I understand that the combinatorial delays (especially the 6ns ones in >|> the slower part that I'm using) will lead to some tradeoffs in accuracy. >|> However, I really don't think that maximum clock rate should be a problem, >|> even with the -6 grade part. My operating freqency is only 5MHz. >|> >|> If my understanding is correct, is there a specific VCO chip that anyone >|> would recommend? If I'm completely off-base, and you're talking about >|> some way to implement the entire loop within an FPGA, please let me know. > >Most designers I know are willing to work pretty hard to avoid analog things like >VCOs. > >Have you checked out Digital PLLs? (Sorry, I don't have a good reference.) > >After you get the hang of it they are pretty simple. The basic idea is to build a >small/fast state machine to wait a while and then look for the next transition. When >it finds the transition, it emits the data bit and a valid signal, and restarts the >scan. If your state machine is running at nX the bit rate, you expect to see the >transition after n clocks. n-1 and n+1 are also reasonable. They just mean that >your clock has drifted a tick relative to the transmitting clock. > >5 MHz is 200 ns. You want to sample at 10X or 16X. That's 20 or 12.5 ns. >You can also process 2 samples in parallel: 40 or 25 ns. If you don't like cramming >that into a corner of your FPGA, consider using a PAL. (Think of it as trading the >VCO for a PAL.) The details probably depend upon what clocks you have available. > >You can probably work out the state machines by spending an evening with graph paper >and pencil. > >Note that just parsing the received data stream is only half of the problem. You >also have to do something with it, like collect it into bytes and pass it on to some >other digital logic. That requires clocking and/or synchronizers. You might, for >example, modify the state machine to generate the clock that drives the next stage of >the system rather than a valid bit. That means the downstream logic might see >shorter than average clock pulses... But it is all digital so once you understand >what is going on it is possible to check all the setup/hold times and be pretty sure >your design will work. A digital PLL is definitely the way to go. For the clock rates you are looking at, putting the entire thing in a FPGA should be the definition of simplicity. It doesn't take up much space either: the counter in the loop is the biggest part. The phase detector state machine is small (can be done with just a few logic cells of what ever flavor your part is. I did one a while back in a Cypress CY7C392 (Altera) which had a divide ratio of about 5K and recovered a quadrature clock and data using about 30% of the chip. That left plenty of room on the chip for data error detection, a BCD to binary converter, holding registers for the 18bit result, a huge timer, and control logic. The best part is you get rid of that pesky analog stuff with its associated tolerance/noise/adjustments/voltages/etc problems in alot less real-estate. I can't direct you to any reference material on DPLL's, I can't really recall seeing much anything on the subject. As the first reply points out, these are pretty easy to do. No magic here. Good Luck with your project. -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 email randraka@ids.net The Andraka Consulting Group is a digital hardware design firm specializing in obtaining the maximum performance from FPGAs. Our services include complete design, development, simulation, and integration of these devices and the surrounding circuits. We also evaluate, troubleshoot and improve existing designs. Please call or email for a brochure.Article: 777
_____________________________________________________________________________
ANNOUNCEMENT AND CALL FOR PAPERS (2 of 2 calls)
_____________________________________________________________________________
CONFERENCE ON
"Using Reconfigurable Technology
for Rapid Product Development"
This conference is part of SPIE's International Symposium on
INTELLIGANT SYSTEMS AND ADVANCED MANUFACTURING
Symposium Chair: Paul S. Schenker, Jet Propulsion Lab
To be held as part of Photonics East '95
Philadelphia, Pennsylvania USA
22-27 October 1995
(over 5000+ attendees at Boston, Photonics94)
Conference Chair: John Schewel, Virtual Computer Corp.,
jas@vcc.com tel.(818)-342-8294
Program Committee: Peter Athanas, Virginia Polytechnic Institute
& State Univ., athanas@vt.edu;
Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com;
Dave Kolmier, Data I/O Corp., davek@data-io.com;
John Watson, Viatek Corp., jlwatson@aol.com
Reconfigurable technologies are new and valuable tools for both
the design and maunfacturing engineer. With the ever-changing needs
in the marketplace and growing worldwide competition, manufacturers
must continually search for methods which accelerate the time to market.
Current reconfigurable hardware platforms enable the use of this technology
for electronic design in rapid product development and implementation.
This conference will present papers that illustrate applications
and techniques for using reconfigurable technology in the product design
and manufacturing cycles.
Papers are solicited in the following and related areas:
- reconfigurable digital components, and their use in
the product development cycle
- reconfigurable analog components, and their use in
the product development cycle
- applications and platforms utilizing reconfigurable
technology for rapid product development
- applications and platforms utilizing reconfigurable
technology for testing, quality assurance, and manufacturing control
TO OBTAIN ALL CALLS FOR PAPERS ELECTRONICALLY
The calls for papers for all conferences in the Photonics East
symposium are available on SPIE Web
(http://www.spie.org/web/meetings/calls/), by anonymous FTP
(ftp://spie.org/meetings/calls/pe95*), or by e-mail file
retrieval (Send a message to info-optolink-request@spie.org with
the following in the message body: send
[meetings.calls]pe95_conf*
For a printed call for papers or other information:
E-mail: spie@spie.org
Fax: 360/647-1445
Phone: 360/676-3290
PHOTONICS EAST DEADLINES
Paper Abstracts Due from Authors: March 27, 1995 (call chair)
Advance Programs due from Chairs: April 24, 1995
Course Descriptions due from Instructors: April 30, 1995
Manuscripts Due from Authors:
August 1, 1995 (on-site books)
September 25, 1995 (post-meeting books)
Article: 778
_____________________________________________________________________________
ANNOUNCEMENT AND CALL FOR PAPERS (1 of 2 calls)
_____________________________________________________________________________
CONFERENCE ON
"Using Reconfigurable Technology for Solving
the Computational and Signal Processing Bottlenecks"
This conference is part of SPIE's International Symposium on
INFORMATION, COMMUNICATIONS, COMPUTER &
TECHNOLOGIES, APPLICATIONS, & SYSTEMS
Symposium Chair: Arun Netravalli, VP Research, Bell Labs, AT&T
To be held as part of Photonics East '95
Philadelphia, Pennsylvania USA
22-27 October 1995
(over 5000+ attendees at Boston, Photonics94)
Conference Chair: John Schewel, Virtual Computer Corp.,
jas@vcc.com tel.(818)-342-8294
Program Committee: Peter Athanas, Virginia Polytechnic Institute
& State Univ., athanas@vt.edu;
Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com;
Dave Kolmier, Data I/O Corp., davek@data-io.com;
John Watson, Viatek Corp., jlwatson@aol.com
Reconfigurable technologies are new and valuable tools for the
development and rapid prototyping of future products. With the
ever-changing standards in the marketplace and growing worldwide
competition, one must continually search for methods which
accelerate the time to market. Current reconfigurable hardware
platforms enable the use of this technology for electronic design
in rapid product development and performance acceleration.
This conference will present papers that illustrate applications
and techniques for solving computational and signal processing
bottlenecks using reconfigurable technology in product design
and software acceleration.
Papers are solicited in the following and related areas:
- reconfigurable digital components, and their use in
communications and image processing
- reconfigurable analog components, and their use in
communications and image processing
- applications and platforms utilizing reconfigurable
technology for rapid product development in communications and
image processing
- applications and platforms utilizing reconfigurable
technology for high-speed computing.
Complete Symposium Programs
COMMUNICATIONS INTERFACING
Emerging High Speed LANs
Workstation & PC Interfacing
Information Protection & Network Security
Standards & Common Interfaces for Information Systems
>>>>Using Reconfigurable Technology for Solving the Computational
& Signal Processing Bottlenecks<<<<(conference above)
MULTIMEDIA SYSTEMS
Creating Content for the Information Highway
Indexing, Accessing & Processing Real Time Media Integration
Issues in Large Commercial Media Delivery Systems
FULL SERVICE RESIDENTIAL NETWORKS
Hybrid Fiber-Coax Systems
Multimedia, Full Service, Broadband Subscriber Networks
New Loop Architectures & Applications for Carriers & Providers
Software Infrastructure for Multi-Service Network Applications
Impact of Interactive Multimedia on Education & the Home
ENTERPRISE SERVICES
Health Care Information Infrastructure
BB Technology & Services for Business & Institutional Users
Video Conferencing & Desktop Video Communications
INFORMATION STORAGE AND MANAGEMENT
Devices & Architectures for High Capacity Rapid Access Storage
Coding & Signal Processing for Data Storage & Retrieval
Error Correction & Modulations Techniques for Magnetic Storage
Digital Image Storage & Archiving Systems
High Density Recording System Technologies
TELECOMMUNICATIONS EQUIPMENT ENGINEERING
Optical Network Engineering & Integrity
Laser Diode Technology for Fiber Optic Communications
Photonic Packaging for Light Source-to-Fiber Coupling
Emerging Components & System Technologies for All-Optical
Photonic Systems
All Optical Communications Systems: Architecture, Control, and
Network Issues
SONET Equipment & Applications in Broadband Networks
Fast Packet Technologies: Frame Relay, SMDS, ATM
WIRELESS GLOBAL COMMUNICATIONS
Cellular Technologies & Services
Enhanced Special Mobile Radio
Wireless Personal Communications Technologies & Services
Wireless Data Communications
TO OBTAIN ALL CALLS FOR PAPERS ELECTRONICALLY
The calls for papers for all conferences in the Photonics East
symposium are available on SPIE Web
(http://www.spie.org/web/meetings/calls/), by anonymous FTP
(ftp://spie.org/meetings/calls/pe95*), or by e-mail file
retrieval (Send a message to info-optolink-request@spie.org with
the following in the message body: send
[meetings.calls]pe95_conf*
For a printed call for papers or other information:
E-mail: spie@spie.org
Fax: 360/647-1445
Phone: 360/676-3290
PHOTONICS EAST DEADLINES
Paper Abstracts Due from Authors: March 27, 1995 (call chair)
Advance Programs due from Chairs: April 24, 1995
Course Descriptions due from Instructors: April 30, 1995
Manuscripts Due from Authors:
August 1, 1995 (on-site books)
September 25, 1995 (post-meeting books)
Article: 779David Hough (dave@sectel.com) wrote: : In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes: : |: I understand that the combinatorial delays (especially the 6ns ones in : |: the slower part that I'm using) will lead to some tradeoffs in accuracy. : |: However, I really don't think that maximum clock rate should be a problem, : |: even with the -6 grade part. My operating freqency is only 5MHz. : |: : |: If my understanding is correct, is there a specific VCO chip that anyone : |: would recommend? If I'm completely off-base, and you're talking about : |: some way to implement the entire loop within an FPGA, please let me know. : : Most designers I know are willing to work pretty hard to avoid analog things : like VCOs. Most definitely. : Have you checked out Digital PLLs? (Sorry, I don't have a good reference.) : : After you get the hang of it they are pretty simple. The basic idea is to : build a small/fast state machine to wait a while and then look for the next : transition. When it finds the transition, it emits the data bit and a valid : signal, and restarts the scan. If your state machine is running at nX the : bit rate, you expect to see the transition after n clocks. n-1 and n+1 are : also reasonable. They just mean that your clock has drifted a tick relative : to the transmitting clock. The problem is that serial data doesn't guarantee a data edge (assuming NRZ). Along with the problems with acquiring, it makes the problem much more difficult. For one, during acquire n+/-1 will not be valid, and after a long string of ones or zeros the same is true. : 5 MHz is 200 ns. You want to sample at 10X or 16X. That's 20 or 12.5 ns. : You can also process 2 samples in parallel: 40 or 25 ns. If you don't like : cramming that into a corner of your FPGA, consider using a PAL. (Think of : it as trading the VCO for a PAL.) The details probably depend upon what : clocks you have available. 10X is probably the lower limit for stablity (assuming real control of the generated clock), I prefer ~100X which is not really practical for most applications. : You can probably work out the state machines by spending an evening with : graph paper and pencil. Or write a little VHDL or Verilog to generate the state machines. : Note that just parsing the received data stream is only half of the problem. : You also have to do something with it, like collect it into bytes and pass : it on to some other digital logic. That requires clocking and/or : synchronizers. You might, for example, modify the state machine to generate : the clock that drives the next stage of the system rather than a valid bit. : That means the downstream logic might see shorter than average clock pulses. : But it is all digital so once you understand what is going on it is possible : to check all the setup/hold times and be pretty sure your design will work. This brings up another problem with intermittent bad samples. The data recovery needs to be smart enough not flip on a single bad sample. As well the clock shouldn't make a radical change to due to a bad sample. We have found that an all digital PLL will take up most of a large FPGA. I will post more after we have finished and published if there is a desire to see such a post. Len -- _______________________________________________________________________ | __ ___ ___ _______ _____ | | /| | /\ \ /| \|\ _ \/\ __\ Len Harold | | | | | \ \ - | \ \ \_\ /_ \ \_/ | | | | \ \ \ \ _|\ \ \ _ \ \ \___ Phone: 208-885-7034 | | | | \ \ \__\/\ \__\ \__\ \__\ \_____\ Fax: 208-885-6840 | | | |* | \/__/ \/__/\/__/\/__/\/_____/ Internet: | | |/\ |/\ lharold@uidaho.edu | | \/ \_/\ University of Idaho | | /| | Microelectronics Research Center | | | | | NASA Space Engineering Research | | | |____________| Center for VLSI System Design | | |/____________/ WWW[URL]: http://www.mrc.uidaho.edu/ | |_______________________________________________________________________|Article: 780
Hi, We am setting up a Rapid Systems Prototyping Laboratory for doing research into software/hardware tools for rapid prototyping of hardware/software systems (based on FPGAs). We are especially interested in the rapid prototyping of distributed multimedia applications. We would very much like to hear your suggestions on the equipments setup (both hardware & software) for this lab. Thank you in advance for your input.Article: 781
I' ll be at the FCCM95 conference in April, which will be my first visit to US. I have some spare days before to travel around. If you wish to help with informations, tips or share some time I'll send you a personal profile on request. Cheers, Andreas -------------------------------------------------------- Andreas Kugel Chair for Computer Science V Phone:(49)621-292-5755 University of Mannheim Fax:(49)621-292-5756 A5 D-68131 Mannheim Germany e-mail:kugel@mp-sun1.informatik.uni-mannheim.de --------------------------------------------------------Article: 782
I am looking for a compiler or traslator tool in order to transform a digital design described into SLIF format or EQN format to a file in XNF format for digital design based on Xilinx FPGA's. Any help will be appreciated. Charles R. Paez Cemisid - Universidad de Los Andes Merida - Venezuela e-mail : cemchp@faces.ula.veArticle: 783
I just had a demo today of an SGI Onyx computer with a Sirius video box. The Onyx has video in and out already, but the Sirius box gives it additional mixing capabilities. The Onyx can display live video on arbitrary 2D surfaces as a texture map! We hooked up a camera and pointed it at the computer screen, and got some nice feedback patterns after messing with the controls for a while. One difference is that the Onyx screen image showed a full frame (2 interlaced fields) while the normal camera looped to monitor feedback goes at the 60 Hz field rate. This slowed things down a bit more than I would like. Perhaps it is adjustable. We didn't play with the mixer yet, but I hope to in the future. It is certainly possible already with the Onyx to distort the image via texture mapping onto an arbitrary surface. We didn't try this either, yet, but it would obviously add a new dimension. Too bad the Onyx costs $200K! I did use it to digitize some frames from a feedback tape I had with me, and these will soon appear on my web page. An unusual feature there is that it is possible to "derotate" the images produced in each field, showing the effect of the nonlinear map more clearly. Tom Holroyd Program in Complex Systems and the Brain Sciences The basis of Florida Atlantic University, Boca Raton, FL 33431 USA stability is tomh@bambi.ccs.fau.edu instability. The 9th Amendment of the U.S. Constitution: "The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people."Article: 784
tomh@bambi.ccs.fau.edu says: > One > difference is that the Onyx screen image showed a full frame (2 interlaced > fields) while the normal camera looped to monitor feedback goes at the 60 > Hz field rate. Sirius can send either 60 fields per second, or 30 interlaced frames per second, to texture memory (software selectable). > Too bad the Onyx costs $200K! Reality Station would be significantly cheaper than that, even with the Sirius board. ....paul -- Paul Spencer Silicon Graphics Advanced Graphics Division spencer@sgi.com Mountain View, CaliforniaArticle: 785
Hi, I happened to read a paper "Area & Time Limitations of FPGA-based Virtual Hardware", Osama T. Albaharna, etc, IEEE International Conference on Computer Design 1994, pp. 184-189. and found a quite interesting fact from it as follows: The author says they found the FPGA area to implement certain set of circuits has overhead of ~100 times compared to the fixed VLSI implementation. Also, the delay overhead is ~10 times, so using the FPGA on the same die with a RISC core would not be feasible with the current technology. (Please forgive me if I am misinterpreting his conclusion). Another paper that attempts such an integration of FPGA and a CPU core on the same chip was "DPGA-Coupled Microprocessors: Commodity ICs for the Early 21st Century", Andre DeHon, IEEE Workshop on FPGAs for Custom Computing Machines, 1994, pp. 31-39. Here, the author just seems to assume that the integration of the FPGA area on the same die is feasible (very well phrased, but without any proof). I just wonder if any of you want to discuss about the limits of this idea (i.e., on-chip FPGA + CPU core) and the above papers. I can provide further information about the papers if you want. (Do the authors read this news group?) Thank you in advance. -- Donglok Kim ICSL (Image Computing Systems Lab) Dept. of Electrical Eng., FT-10 University of Washington Seattle, WA 98195 Phone) 543-1019 FAX) 543-0977Article: 786
In Article <3j034s$rn6@newshound.uidaho.edu> lharold@mrc.uidaho.edu (Len Harold) writes: >David Hough (dave@sectel.com) wrote: >: In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes: >: |: I understand that the combinatorial delays (especially the 6ns ones in >: After you get the hang of it they are pretty simple. The basic idea is to >: build a small/fast state machine to wait a while and then look for the next >: transition. When it finds the transition, it emits the data bit and a valid >: signal, and restarts the scan. If your state machine is running at nX the >: bit rate, you expect to see the transition after n clocks. n-1 and n+1 are >: also reasonable. They just mean that your clock has drifted a tick relative >: to the transmitting clock. > >The problem is that serial data doesn't guarantee a data edge (assuming NRZ). >Along with the problems with acquiring, it makes the problem much more >difficult. For one, during acquire n+/-1 will not be valid, and after a long >string of ones or zeros the same is true. > That is true, however, I got around the problem as follows. My phase detect state machine required 15 consecutive samples at the same logic level before signalling a transition. My divider was set to approximately match the expected buried clock, and would free run in the absence of a detected transition. The divider provided a data sample pulse and quadrature clock outputs so that the data got sampled a few times and 'voted' on well away from the transition region. If I remember right, the divider also prevented a data transition detection except within a window of the divider count. This kept the thing from going ape if there was a radical shift in the incoming phase. In my case, I had a pretty big ratio between the sample clock and the data clock so I had the luxury of a lot of samples and plenty of time for serial processing (my incoming data rate was pretty low) For higher data rates you lose some of the oversampling so the design gets more challenging. Also, in cases where you need to have a larger capture range, you may need a more complicated divider whose divide ratio gets bumped up or down as a result of repeated phase errors in the same direction. That takes a little more than twice the logic the fixed divide needed. The rate of the increment with respect to the frequency of the phase error will determine the loop stability and the time required to lock to a new frequency or phase. Working with phase encoded data such as a manchester code makes it a lot easier since the clock information is always there (you can only miss one transition at a time). >: 5 MHz is 200 ns. You want to sample at 10X or 16X. That's 20 or 12.5 ns. >: You can also process 2 samples in parallel: 40 or 25 ns. If you don't like >: cramming that into a corner of your FPGA, consider using a PAL. (Think of >: it as trading the VCO for a PAL.) The details probably depend upon what >: clocks you have available. > >10X is probably the lower limit for stablity (assuming real control of the >generated clock), I prefer ~100X which is not really practical for most >applications. > Also true. If your input signal is clean, I wouldn't go below 16X. Noisy inputs (phase noise) will require a higher sample rate to keep it stable. >: You can probably work out the state machines by spending an evening with >: graph paper and pencil. > >Or write a little VHDL or Verilog to generate the state machines. This may be why you are taking most a large FPGA. My experience shows a synthesized design tends to be about 1.6X the size of a handcrafted design. I think the design I described above used a little over 30% of a Cypress CY7C392 (Altera). > >: Note that just parsing the received data stream is only half of the problem. >: You also have to do something with it, like collect it into bytes and pass >: it on to some other digital logic. That requires clocking and/or >: synchronizers. You might, for example, modify the state machine to generate >: the clock that drives the next stage of the system rather than a valid bit. >: That means the downstream logic might see shorter than average clock pulses. >: But it is all digital so once you understand what is going on it is possible >: to check all the setup/hold times and be pretty sure your design will work. > >This brings up another problem with intermittent bad samples. The data >recovery needs to be smart enough not flip on a single bad sample. As >well the clock shouldn't make a radical change to due to a bad sample. > See the comments above for limiting the phase slew and time filtering the data. >We have found that an all digital PLL will take up most of a large FPGA. >I will post more after we have finished and published if there is a desire >to see such a post. > -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 email randraka@ids.netArticle: 787
I read in this week's EE Times that Innovative Synthesis Technologies (IST),
a small French company that was trying to take French university developed
FPGA synthesis into the commercial market shut down its Silicon Valley
office after Bruce Bourbon, a ex-Chairman of Open Verilog International (OVI),
turned down the offer of becoming IST's CEO. (It's rumored that what triggered
the shut down was their venture capital people didn't want to pony up the
$5 million IST requested leaving IST in a lurch.)
As far as I know, Actel was the only company that signed an OEM deal with IST
to resell their software. If you were a user of this tool either through the
Actel OEM process or through some other independant IST sales channel, I'd
like to hear what you thought of it in a technical sense. Was this a case of
the financial people killing a possibly good product because they saw its
market as too competitive, was the tool they were offering buggy & ugly or
was this just a bad time to try to commercialize French university developed
FPGA synthesis tools?
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 3196 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 3196 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 788Luc Deriemaeker <llderiem@vnet3.vub.ac.be> writes: >Is there anyone out there who played with the kit before and can >give me an evaluation. Is the soft bugfree etc... I've had it die a couple of times without any warning during some operations. Save before verifying. As to real bugs, like false operation, none encountered so far but I haven't used it that much yet. Certainly value for the money, but I'd give one arm for a simulator. >not the Gal there is only a loader for JEDEC files. Doe anyone know > if there exist a simple compiler on the net that can create this >JEDEC files ? Check out ftp.intel.com. PLDShell should be still available despite that the business was bought out by Altera. I haven't tried yet if the fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I can't see why not. The software even includes a simulator - I'd use the Intel/Altera parts, if only I had a programmer... -- Segmented Memory Helps Structure SoftwareArticle: 789
Len Harold (lharold@mrc.uidaho.edu) wrote: : We have found that an all digital PLL will take up most of a large FPGA. : I will post more after we have finished and published if there is a desire : to see such a post. Yes please post more on this topic. Could some body post something on the different approach/ algorithm on DPLL. -- Edwin Tsang, Email:edwint@bnr.ca ,Bramalea Lab, Northern Telecom Opinion is mine only and I reserved the right to change itArticle: 790
Hi, I am looking for the information (call for paper, registration) for "FPGA Custom Computing Machine workshop". Help please! Chih-chang Lin UC, Santa BarbaraArticle: 791
Hi, I am looking for the information (call for paper, registration) for "FPGA Custom Computing Machine workshop". Help please! Chih-chang Lin UC, Santa BarbaraArticle: 792
***FINAL CALL FOR CONTRIBUTIONS*** FIFTH INTERNATIONAL WORKSHOP on FIELD PROGRAMMABLE LOGIC and APPLICATIONS Paper deadline: 10 March, 1995 Notification : 5 May, 1995 Final version : 1 July, 1995 Workshop: 30 August - 1 September, 1995 Oxford University, UK AIM The aim of this workshop is to bring together workers from throughout the world for a wide ranging discussion of all forms of field programmable logic (but particularly field programmable gate arrays) and their applications. It is intended to discuss the increasing range of device types, industrial applications, advanced CAD developments, research applications, novel systems architectures and educational experiences. The workshop will include regular presentations, posters and discussion sessions and it is expected that most of the delegates will wish to make some contribution to one or more of these. The workshop is the fifth in a series of workshops which were held in Oxford (1991 and 1993), Vienna (1992) and Prague (1994). SCOPE Field Programmable Logic has been available for a number of years, but the increasing power and variety of devices now available is extending its role from that of simply being a convenient way of implementing the system 'glue logic' to an increasing ability to implement mainstream system functions. The speed with which devices can be programmed makes them ideal for prototyping and for education, the reprogrammable devices are opening up sophisticated new applications and new hardware/software trade-offs. CAD is being developed for automatic compilation of advanced designs and routes to custom circuits are now available. The scope of the workshop includes, but is not be limited to, the following aspects: * New and future commercial devices * Novel chip architectures * New software and hardware development tools * Bridges to other CAD and to custom circuits * High-level design and compilation research * Industrial applications and experiences * Trade-offs between devices, architectures and technologies * Benchmark comparisons * Smart applications * Custom computers * Novel machine paradigms and system architectures * ASIC emulators, hardware modellers and compiled accelerators * Fault models, testability methods, reliability * Educational experiences and opportunities CALL FOR CONTRIBUTIONS Contributions are invited for regular presentation, poster and discussion sessions. Prospective authors are invited to submit an abstract of at least 500 words or a full paper by 3rd March, 1995 to: Ms. Laura Duffy Field Programmable Logic Workshop Secretary, CPD Unit, Department for Continuing Education, University of Oxford, Rewley House, 1 Wellington Square, OXFORD OX1 2JA, England. Tel.: +44 865 270360 Fax: +44 865 270708 e-mail: cpdmail@vax.ox.ac.uk Please preface this by your full correspondence address including email and fax, a list of (at most) 5 one-line statements that best encapsulate the essence of your proposed contribution, and a note of your preferred presentation format. Please mail 10 copies if possible, but submissions by email or fax will be accepted. Notification of acceptance will be posted by 5th May and full papers (up to 12 pages including Figures -- the format instructions will be available at an FTP site) must be received by 1st July to guarantee distribution at the workshop. Selected contributors will be invited to submit their papers to be included in an edited proceedings to be published in book form after the workshop. (The proceedings of the 1991 and 1993 workshops are available from Abingdon EE&CS Books, 49 Five Mile Drive, Oxford OX2 8HR, UK.) Potential exhibitors and tutorial presenters are also invited to contact the secretariat. PROGRAMME COMMITTEE Doug Amos, Altera Corp, USA Jeffrey Arnold, IDA SRC, USA Peter Athanas, Virginia Tech, USA Stan Baker, PEP, USA Erik Brunvand, U. of Utah, USA Pak Chan, U. of California (Santa Cruz), USA Barry Fagin, Dartmouth College, USA Patrick Foulk, Heriot-Watt U., UK John Gray, Xilinx Development Corp., UK Herbert Guenbacher, Vienna Technical U., Austria Reiner Hartenstein, U. Kaiserlautern, Germany Brad Hutchings, Brigham Young U., USA Sinan Kaptanoglu, Actel Corp., USA Craig Lytle, Altera Corp, USA Wayne Luk, Imperial College, UK Amr Mohsen, Aptix, USA Will Moore, Oxford U., UK Peter Noakes, Essex U., UK John Oldfield, Syracuse U., UK Ian Page, Oxford U., UK Franco Pirri, U. of Firenze, Italy Jonathan Rose, U. of Toronto, Canada Michal Servit, Czech T. U., Czech Republic Herve Touati, DEC Paris Research, France Steve Trimberger, Xilinx, USA LOCAL DETAILS The workshop will be held at the University of Oxford from 30th August to 1st September 1995 with meals and accommodation available in 16th century Jesus College on the nights of 29th to 31st August. The cost of the workshop is still to be decided and will be inclusive of proceedings, lunches and banquet. The University and its Colleges are located in the centre of this historic city which has fast connections to London and its airports. Oxford and the surrounding area has numerous cultural and tourist attractions and has plenty to interest accompanying partners. FURTHER DETAILS FROM: Ms. Laura Duffy Field Programmable Logic Workshop Secretary, CPD Unit, Department for Continuing Education, University of Oxford, Rewley House, 1 Wellington Square, OXFORD OX1 2JA, England. Tel.: +44 865 270360 Fax: +44 865 270708 e-mail: cpdmail@vax.ox.ac.uk or Dr. Will Moore, Department of Engineering Science, University of Oxford, Parks Road, OXFORD, OX1 3PJ, England. Tel.: +44 865 273187 Fax: +44 865 273010 e-mail: will.moore@eng.ox.ac.ukArticle: 793
The IDA Supercomputing Research Center (SRC) maintains a World Wide Web page for the comp.arch.fpga newsgroup that contains: 1) The group charter; 2) An archive of posted messages with various retrieval mechanisms; 3) A list of upcoming events of interest to the custom computing community; 4) Pointers to organizations engaged in FPGA based computing research; 5) Several other interesting links. This page can be found at: http://www.super.org:8000/FPGA/caf.html Note the new URL: we are finally running htpd. The old 'ftp' URL will no longer work. This page is still very much under construction, so any comments or additions are welcome. We would especially like to solicit contributions to the bibliography and a FAQ list. -jeff ------ Jeffrey Arnold IDA Supercomputing Research Center 17100 Science Dr. Bowie, MD 20715 email: jma@super.orgArticle: 794
Can someone please enlighten me as to what is the percentage of area occupied by SRAM configuration cells in an SRAM based FPGA? The ones that come to mind are the Xilinx 3/4000, AT&T ORCA, Atmel 6000, Altera Flex 8000. Any pointers to the literature will be much appreciated. Thank you, Mircea -- Mircea R. Stan | "Without immortality the whole world would UMass, ECE Dept. | be nonsense, all of creation an absurdity." Amherst, MA 01003 | Karl F. GaussArticle: 795
About french software, I can think of Frederic PETROT @ Equipe Alliance, Labo. MASI , they have done some good work...
By the way is there a proposal to moderate the following newsgroups.
comp.arch.fpga and comp.cad.synthesis .
I am sick of having to subscribe to 20 mailing lists, because
thats the only way, news gets around now.
--------------------------------------------------------------------------------
I read in this week's EE Times that Innovative Synthesis Technologies (IST),
a small French company that was trying to take French university developed
FPGA synthesis into the commercial market shut down its Silicon Valley
office after Bruce Bourbon, a ex-Chairman of Open Verilog International (OVI),
turned down the offer of becoming IST's CEO. (It's rumored that what triggered
the shut down was their venture capital people didn't want to pony up the
$5 million IST requested leaving IST in a lurch.)
As far as I know, Actel was the only company that signed an OEM deal with IST
to resell their software. If you were a user of this tool either through the
Actel OEM process or through some other independant IST sales channel, I'd
like to hear what you thought of it in a technical sense. Was this a case of
the financial people killing a possibly good product because they saw its
market as too competitive, was the tool they were offering buggy & ugly or
was this just a bad time to try to commercialize French university developed
FPGA synthesis tools?
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
Article: 796Check out ftp.intel.com. PLDShell should be still available despite that the business was bought out by Altera. I haven't tried yet if the fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I can't see why not. The software even includes a simulator - I'd use the Intel/Altera parts, if only I had a programmer... Should be able to pick up a programmer that'll handle these pretty inexpensively... I was all set to use the Intel parts until the business got moved to Altera, but after being kicked in the head enough times over the last 6 years, Altera has become a *very* dirty word for me 8-o -- Roger Williams <roger@coelacanth.com> Coelacanth Engineering | Numeric stability is probably not all Middleborough, Mass | that important when you're guessing...Article: 797
iisakkil@alpha.hut.fi (Mika Iisakkila) wrote: > > Check out ftp.intel.com. PLDShell should be still available despite > that the business was bought out by Altera. I haven't tried yet if the > fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I > can't see why not. The software even includes a simulator - I'd use > the Intel/Altera parts, if only I had a programmer... > -- Use the iFX780 or iFX740, and alas, you only need a special cable attached to the parallel port to program them. Schematics available from me upon request. -SamiArticle: 798
dong@icsl.ee.washinton.edu (Dong-Lok Kim) wrote: > > Hi, > > I happened to read a paper > "Area & Time Limitations of FPGA-based Virtual Hardware", .. There might be a significant overhead when compared to a fixed VLSI solution both real-estate- and performance-wise, but when you compare trying to implement the same features with a software-only solution the odds are reversed. Consider having a DSP processor without the autoincrementing bit-reverse address pointers that speed up the calculation of a FFT so neatly. You could do that with software in a risc processor, or you could have a fixed VLSI solution as in a modern DSP processor. But if you had the configurable logic gates to implement this besides of a more or less standard processor you could do the FFT with a speed comparable to a VLSI solution, and by reconfiguring you could also do many other things. Sami Sallinen sjs@varian.fi Systems Engineer, Varian-Dosetek Oy Tel. +358-0-43077212 Fax +358-0-4554585 #include <disclaimers.h>Article: 799
What is the experiences of reduction in power dissipation/consumption when moving an FPGA design to a Gate Array. Obviously there are two different situations A) 1 FPGA -> 1 Gate Array. Is a factor 4 power gain reasonable to expect? B) N FPGA -> 1 Gate Array. Here the power gain should be considerably larger due to reduced io power. Opinions are welcome Robert Tjarnstrom
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