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
> So- I think benchmarks are good, in general, but authors need to make sure > not to obscure the impact on the total design methodology by too narrow > a focus on individual tasks. One thing I think vendors have to guard against is the temptation to offer a methodology as a product. Engineers are a fairly sophisticated bunch who generally prefer to define their own methodology. I know I really go for the superior point tools rather than go with something that attempts to address the methodology: 1) You need to know what the tool and the methodology is doing anyways, obscuring it behind layers of automation doesn't make it any easier. 2) You wind up with a methodology that you're not really happy with, because your optimal approach isn't marketable. 3) You don't have as much of a choice in point tools and have to settle for what ever happens to be integrated in the suite. The tools that have really made it in the market have been the ones based on standards and interoperability ( and performance, of course ). Vendors have been offering GUI EDA frameworks for a while, but they'll never catch on. Users are more concerned with the business end of the tool, rather than the handle. John WilliamsArticle: 476
Hi, we would like to build some BIT-SERIAL circuits and watch them run
on our FPCB/FPLDs.
We would appreciate any pointers to texts, articles, people, even companies
that could tell us about the finesses of designing, for example, a hand-held
calculator. We need help on every possible level, ANY feedback would be
appreciated please:
* bit-serial arithmetic (even floating-point)
* problems with control of bit-serial datapaths
* memory/register design for bit-serial access
* clever "canned" designs (described maybe in VHDL, BDS, even as gate
netlists) for adding, multiplying, etc.
* "definitive works" on the subject
"Nibble-wide" techniques would also be interesting, but for pedagogical
reasons it would be easier to stick with single-bit-serial to begin with.
About all I am aware of myself are Peter Denyer's books (U. Edinburgh),
these date back to 1985 as I recall, the focus was on full-custom VLSI
implementation and there was no discussion on controlling the datapath
(just, "there exists a controller").
If it matters we're working with the ORCA FPLD, on an APTIX GP4, and our
front-end is an RTL capture tool, and/or Viewlogic.
Thanks !
Glenn Jennings Email: glenn@sm.luth.se
Div. of Computer Engineering Tel: (+46)920-91763 Alt: (+46)920-91000
Lulea University of Technology Fax: (+46)920-72191 Alt: (+46)920-97288
S-971 87 Lulea, SWEDEN LaTeX: Lule{\aa}
Article: 477
---------------------------------------------------------------------------------
(STUDENT PERIOD OFFERED in FRANCE)
IMAGE PROCESSING on FPGAs
Thomson CSF and LIBr
Brest
---------------------------------------------------------------------------------
1 CONTEXT
The project concerns a programming environment for a dedicated programmable
electronic board including (a local net of) 6 FPGAs. This board has been devel-
oped last year in Thomson, and will be the hardware support for a PHD dealing
with its customization using a high level and full-integrated programming lan-
guage. This project will essentially deal with signal and image processing, and
the PHD is to begin in the coming weeks.
We are looking for a student to work jointly with
the PHD candidate on this subject.
The project is located in Brest, and is led jointly by Thomson/RCM/CEB
and Brest computer science laboratory (LIBr at U.B.O.).
2 COMETT PROJECT
( A preference will be given to candidates from Northern Europe.)
The COMETT student will work upon the first implementation of image /
signal processing algorithms on the multi-FPGAs board, using mainly existing
tools such as the Xilinx programming environment. This implementation will
follow as far as possible the state of the art of parallel or systolic design, but
the main goal is to have first the board running with a "real" algorithm.
So the student has to know about Xilinx, FPGAs, Unix, C language, parallel
and systolic solutions, ... He/she might also have already worked on signal or
image processing. Moderate french speaking needed.
The work will be done in collaboration with the PHD student, and with
Brest University Parallelism lab (LIBr). It could be a 4 or 5 months period,
during 95 (no real constraints for the moment). May be the best would be from
April/May to August/September, so that the PHD student could have begun
to work on the subject, and give a better help to the COMETT student.
While Thomson cannot receive a foreigner permanently, the work will be
based at university lab, and the student will be "invited" two or three days a
week in Thomson (that is a detail, but it is good to know there will be two work
places).
Financing is half Thomson half COMETT, and it is expected to be about
4000 francs per month. A "student room" would be available at a moderate
cost.
3 CONTACTS / FOLLOWING DETAILS
Please contact either :
Gilles Craignou at Thomson-CSF/RCM/CEB
tel (33) 98.31.23.67 or fax (33) 98.31.25.23
or
Bernard Pottier at U.B.O.
tel (33) 98.01.62.15 or fax (33) 98016131
e-mail pottier@univ-brest.fr
__________________________________________________________________________________
Bernard Pottier Laboratoire d'Informatique de Brest * Projet ArMen
Universite de Bretagne Occidentale, 6 avenue Le Gorgeu, BP 809, Brest 29285 FRANCE
tel (33) 98 01 62 15. e-mail pottier@univ-brest.fr fax (33) 98 01 61 31
ftp ftp.univ-brest.fr pub/dept_info/ArMen/publi
Article: 478We're looking into ASIC emulation of the Quickturn variety and are interested in experiences with Quickturn or any other FPGA-based emulation systems. Can you just drop a design on it and start running test vectors through, or do you still have do some FPGA-like hardware design? Does it scale well to large emulations, say of a complete CPU or even multiple chips? We hear that the emulation runs 100 times slower than actual hardware (which seems a little slow). Are the FPGAs really that much slower individually or is it a problem with their combination into a larger system? Any insights, experiences and/or references to articles describing experiences would be greatly appreciated. I will summarize responses for the net. Thanks again. ********************************************************************** NSF Engineering Research Center for Computational Field Simulation ********************************************************************** Daniel H. Linder linder@erc.msstate.edu NSF Engineering Research Center for CFS (601) 325-2057 P.O. Box 6176 fax: (601) 325-7692 Miss. State, MS 39762 **********************************************************************Article: 479
linder@ERC.MsState.Edu (Dan Linder) writes:
> We're looking into ASIC emulation of the Quickturn variety and are
> interested in experiences with Quickturn or any other FPGA-based emulation
> systems.
>
> Can you just drop a design on it and start running test vectors
> through, or do you still have do some FPGA-like hardware design?
Yes you can. All the FPGA-specific details are completely contained
within the design compiler, which does the technology mapping from the
source netlist and libraries into the FPGAs. The emulation user sees
the design elements, netnames, etc. in the design's terms. After running
your vectors, or even without vectors, you can go directly in-circuit.
> Does it scale well to large emulations, say of a complete CPU or even
> multiple chips?
It scales very well to large emulations. Intel, Sun, and many other
major developers are emulating entire CPU designs, at 2 million gates and more.
Quickturn's System Emulator M3000 has a 3 million gate capacity, with
provisions for multi-M3000 systems that allow over 10 million gate emulations
off the shelf. Most CPU developers and many ASSP and ASIC projects now use
Quickturn emulators to run OSs and applications before tapeout.
> We hear that the emulation runs 100 times slower than actual hardware
> (which seems a little slow). Are the FPGAs really that much slower
> individually or is it a problem with their combination into a larger system?
The programmable interconnect inside and between FPGAs does take more time
than real metal and wires, because of RC delays in pass transistors and many
more chip-crossings. 100X slowdown is an upper bound in our experience.
Most emulations run from 1 to 8 MHz. That's 3 to 5 orders of magnitude faster
than cycle-based simulators, which is the difference between running lots of
real code and just doing vectors or one OS boot. Multi-million-gate CPU
emulations are slower than 200K gate ASIC emulations, but the CPU projects find
the speed is plenty for what they do so it all works out. ASICs typically run
at multi-MHz in current-generation emulators, and there are many techniques
for successfully matching the target system's speed to the emulator.
> Any insights, experiences and/or references to articles describing
> experiences would be greatly appreciated. I will summarize responses for
> the net. Thanks again.
A detailed and quantitative article written by a user is called "Logic Design
Aids Design Process", by Jim Gateley of Sun, in the July 1994 issue of
ASIC & EDA. It's an account of the MicroSPARC II project's experiences with
the Quickturn Enterprise (previous generation) logic emulator on a 200K
gate 32-bit SPARC CPU.
"During the 25 days prior to tapeout, the emulated processor and testbed
system successfully executed power-on self tests and open boot PROM, booted
single- and multi-user Solaris, Open Windows, and Open Windows applications.
Altogether, emulation logged 15 bugs and enhancements against MicroSPARC II,
PROM, and the kernel before tapeout. First silicon was very clean.
MicroSPARC II shipped three months early."
--Mike Butts, Emulation Architect,
Quickturn Design Systems (mbutts@qcktrn.com)
--
Mike Butts, Portland, Oregon mbutts@netcom.com
Article: 480In article <mbuttsD03IM1.G8C@netcom.com>, Mike Butts <mbutts@netcom.com> wrote: >real code and just doing vectors or one OS boot. Multi-million-gate CPU >emulations are slower than 200K gate ASIC emulations, but the CPU projects find >the speed is plenty for what they do so it all works out. ASICs typically run Interesting question: What is the slowest "acceptable" speed for logic emulation of a CPU? In particular, would 1/256 full-speed be acceptable?Article: 481
In article 94Nov30111210@gemini.ERC.MsState.Edu, linder@ERC.MsState.Edu (Dan Linder) writes: >We're looking into ASIC emulation of the Quickturn variety and are >interested in experiences with Quickturn or any other FPGA-based emulation >systems. Can you just drop a design on it and start running test vectors >through, or do you still have do some FPGA-like hardware design? Does it >scale well to large emulations, say of a complete CPU or even multiple >chips? We hear that the emulation runs 100 times slower than actual >hardware (which seems a little slow). Are the FPGAs really that much >slower individually or is it a problem with their combination into a larger >system? No experiences except on our homegrown system, however you should not be surprised at system level, or large emulutions running 100 times slower. Remember that CPU bus speeds (internal) are now running at 100 +MHz, think of the wire length busses have to run through on a board that will fit such a design for emulation. There is no way you will get anywhere near that speed. However a drop in speed by only 100 is small potatoes, when you think of the drop in speed when simulating. Good luck. Richard Dept of Electrical and Computer Eng. University of ManitobaArticle: 482
White Mountain's "DSP Summit" Fall Newsletter can now be accessed on the world wide web via DSPnet. This is the second issue of this Newsletter to appear on the WWW. The issue features the following information: - C5x Development System - DSP hits the Internet - JTAG Emulation Principles - PC vs. Sun Environment To access this newsletter with a WWW browser go to URL: http://www.dspnet.com Access with a common terminal: telnet dspnet.com (and login as lynx) DSPnet is free (you just have to register once when you login for the 1st time)Article: 483
I believe one of the Mistral (sp?) tools that are part of Mentor Graphics DSP Station (Mistral I or Mistral II) can decompose an algorithm into a bit-serial representation. The foundation of this tool set is work that was done in the Phillips Research Labs in Europe. Once implemented the design can be written out as RTL VHDL or Verilog HDL. Regards, Mark -- /* Mark A. Indovina, Principal Staff Engineer mark_indovina@pts.mot.com */ /* Motorola Applied Research, Advanced IC Technology Laboratory */ /* Mail Stop 63, 1500 Gateway Boulevard, Boynton Beach, FL 33436-8292 USA */ /* phone: 1-407-364-2379, fax: 1-407-364-3904 ...just speaking for me */Article: 484
Article: 485
Sorry about the blank note. Here is another try! We recently benchmarked Altera's VHDL option to Synopsys VHDL Synthesis and obtained mixed results. Has anyone performed a similar benchmark. We are mainly looking at how well Altera's VHDL option does in timing and area results when compared to Synopsys synthesis approach. Any comments would be appreciated. :) Thanks. You may e-mail to me at: JDalmau.es_ae@xerox.comArticle: 486
In article <3bl845$a5e@vine.cp10.es.xerox.com> dalmau@xerox.com (John Dalmau) writes:
>We recently benchmarked Altera's VHDL option to Synopsys VHDL Synthesis and obtained mixed results. Has anyone performed a similar benchmark. We are mainly looking at how well Altera's VHDL option does in timing and area results when compared to Synopsys
>synthesis approach. Any comments would be appreciated. :) Thanks. You may e-mail to me at: JDalmau.es_ae@xerox.com
Based on our trials with Altera VHDL-option using codes initially written for
Synopsys, my opinion is that you should go the Synopsys route. The constraints
for the syntax place quite a lot of restrictions compared to the subset, which
is currently supported by Synopsys. This is purely from the technical point of
view, certainly there is on other hand a difference between the price tags...
Anyway, I'm eagerly waiting for the promised enhancements in Altera VHDL
support, but .... those are not yet here.
Regards,
Veli-Matti Karppinen
---------------------------------------------------------------
Veli-Matti Karppinen Fincitec Oy
P.B. 11, FIN-94601 Kemi Tel. +358 698 221 490
Finland Fax. +358 698 221 561
" Once you have flown, you will walk your eyes turned towards
the sky, for there you've been and there you long to return "
-- da Vinci
Article: 487Hi everyone, Like lots of other people we (we=just two people for now) are interested in looking at FPGA-based computing (for image related work) - and we've just got a little money to spend on it. We have Powerview running on Sparcs as our development tool, and would ideally like to work with fairly fine-grained FPGAs. A lot of people that have published work in this area seem to have done something similar - developed a board with around 4-6 FPGAs, a programmable cross-bar switch, and some K of RAM. Is anyone prepared to sell one of these boards to us? The obvious question is, why don't we too produce our own? Unfortunately, we have a deadline to spend our money by - and its too short to do that (added to which, this is a CS department, not EE, so we don't have any arrangements for board manufacture). Any suggestions gratefully received! (I guess this may be a common problem so I'll summarize if I get email replies) Graham -- -------------------------------------------------------------------- Graham Seaman, School of Computer Science, University of Westminster, 115 New Cavendish St. London W1M 8JS email: seamang@wmin.ac.uk www: http://www.wmin.ac.uk/~seamangArticle: 488
FPGA `95 Advance Program
------------------------
1995 ACM Third International Symposium on Field-Programmable Gate Arrays
February 12-14, 1995
Marriott Hotel, Monterey, CA, USA
Note: The Symposium location is now Monterey.
Sponsored by ACM SIGDA, and Actel Corp., Altera Corp. and Xilinx, Inc.
Field-Programmable Gate Arrays (FPGAs) have revolutionized ASIC design by
providing fast turnaround and negligible overhead cost. The challenge in
FPGA research is to improve the speed and density of the devices, and find
new CAD synthesis algorithms that make effective use of the new architectures.
The objective of this symposium is to bring together people who are working
in the many areas of research that are necessary to make a complete FPGA and
high-capacity PLDs.
The technical program consists of papers concerning FPGAs and High-Capacity
PLD device architecture, Computer-Aided Design of these devices, architecture
of multi-FPGA systems and CAD tools associated with these systems. In
addition, there are several papers concerning applications of programmable
logic.
The Symposium will be of interest to those developing FPGA architectures, both
at the chip and board level, and those developing CAD algorithms for FPGAs.
The Symposium is not of direct interest to immediate users of FPGAs.
General Chair: Pak K. Chan, UC Santa Cruz
Program Chair: Jonathan Rose, University of Toronto
Program Committee
Duncan Buell, SRC
Pak K. Chan, UCSC
Jason Cong, UCLA
Carl Ebeling, U. Washington
Ewald Detjens, Exemplar
Frederic Furtek, Atmel
Dwight Hill, Synopsys
Sinan Kaptanoglu, Actel
John McCollum, Actel
Jonathan Rose, U. Toronto
Richard Rudell, Synopsys
Rob Rutenbar, CMU
Takayasu Sakurai, Toshiba
Martine Schlag, UCSC
Tim Southgate, Altera
Steve Trimberger, Xilinx
Program
-------
Sunday February 12, 1995
6:00pm Registration
7:00pm Welcoming Reception, Marriott Hotel, Monterey
Monday February 13, 1995
8:20am Opening Remarks
Session 1: General Purpose Architecture
Chair: Tim Southgate, Altera
8:30am On Designing ULM-Based FPGA Logic
Modules, S. Thakur, D.F. Wong, U. of Texas
8:50am Using Architectural "Families" to Increase FPGA
Speed and Density, V. Betz, J. Rose, U. Toronto
9:10am Design of FPGAs with Array I/O for Field
Programmable MCM, J. Darnauer, J. Ramirez,
W. W-M. Dai, U. of Cal. Santa Cruz
Posters: General Purpose Architecture
9:30-10:30am Coffee & Posters
Session 2: Field-Programmable Systems
Chair: Carl Ebeling, University of Washington
10:30am TIERS: Topology Independent Pipelined Routing
and Scheduling for Virtual Wire Compilation,
C. Selvide, A. Agarwal, M. Dahl, J. Babb, Virtual
Machine Works, MA.
10:50am Logic Partition Orderings for Multi-FPGA
Systems, S. Hauck, G. Borriello, U. Wash.
11:10am An FPGA-Based Reconfigurable Co-processor
Board Utilizing a Mathematics of Arrays, H.
Pottinger, W. Eatherton, J. Kelly, T. Schiefelbein,
U. of Missouri - Rolla
Posters: Field-Programmable Systems 11:30-12
LUNCH 12:00 - 1:30
Session 3: Applications I
Chair: Pak K. Chan, UCSC
1:30pm High-Energy Physics on DECPeRLE-1
Programmable Active Memory, L. Moll,
J. Vuillemin, P. Boucard, Digital Equip. Corp,
Paris Res. Lab, France
1:50pm HGA: A Hardware-Based Genetic Algorithm,
S. D. Scott, A. Samal, S. Seth, Wash. Univ,
U. of Nebraska-Lincoln
2:10pm The U.S.C. Multiprocessor Testbed: A Rapid
Prototyping Engine, K. Oner, L. Barroso,
S. Iman, J. Jeong, K. Ramamurthy, M. Dubois,
U. Southern California
Posters: Applications
2:30-3:30pm Coffee & Posters
Session 4: Logic Synthesis
Chair: Richard Rudell, Synopsys
3:30pm Simultaneous Depth and Area Minimization in
LUT-Based FPGA Mapping, J. Cong,
Y-Y. Hwang, U. of California, L.A.
3:50pm Synthesis of Signal Processing Structured
Datapaths for FPGAs Supporting RAMs and
Busses, B. Haroun, B. Sajjadi, Concordia
University.
4:10pm On Nominal Delay Minimization in LUT-Based
FPGA Technology Mapping, J. Cong, Y. Ding,
UCLA.
Posters: Logic Synthesis and Co-Design
4:30-6:00pm Free time/Posters
Dinner 6:00-7:30pm
7:30-9:00pm PANEL
The Architecture/Software Boundary:
Motherhood & Lies.
The most crucial element in the creation of an FPGA is the
interaction between the device architecture and the software
tools that map circuits into the device. The architect should
determine the ability of the placement and routing software,
for example to:
i. Deal with routing architecture's overall structure
(such as symmetric vs. asymmetric; hierarchical vs.
flat, segmented routing etc.)
ii. Handle special purpose connections, such as carry
chains, local interconnect or hard-wired connections.
iii.Route typical circuits with the fixed total amount of
interconnect. For example, should different-sized
parts be given different quantities of routing?
Similarly the architecture should be able to deal with the
capability of the logic synthesis tools to handle:
i. The structure and function of the logic block.
ii. Special logic block features such as adder logic, clock
qualifiers and logic sharing capability.
iii.The effect of the synthesis on the routability of the
synthesized netlist.
Although FPGA vendors and academic architects will
immediately agree with that this interaction is essential, and
is indeed a motherhood issue, it is actually rare that these
interactions are enforced. Similarly, synthesis vendors (and
University CAD researchers) may claim to produce FPGA
architecture-specific algorithms but the reality is otherwise.
What makes it so difficult?
Is interaction really important, or will the effects of poor
interaction be swallowed by the next generation IC process
advance? Perhaps some very clever interactions can produce
major density and speed gains FPGA devices.
If interaction is difficult to enforce for general-purpose
FPGA architectures, will it be possible to create a next
generation of special-purpose architectures?
This panel will explore these issues by bringing together
several people from the FPGA vendor community, the
FPGA user community, synthesis vendors and researchers.
Tuesday February 14, 1995
Session 5: Architecture of Special-Purpose Structures
Chair: Steve Trimberger, Xilinx
8:30am Revisiting the Cascade Circuit in Logic Cells of
Lookup Table Based FPGAs, N-S. Woo, AT&T
Bell Labs, N.J.
8:50am Architecture of Centralized Field-Configurable
Memory, S.J.E. Wilton, J. Rose, Z.G. Vranesic,
U. Toronto
9:10am A Field-Programmable Mixed-Analog-Digital
Array, P. Chow, P. Chow, P.G. Gulak,
U. Toronto
Posters: Special-Purpose Architecture
9:30-10:30am Coffee & Posters
Session 6: Placement, Routing & Testing
Chair: Jason Cong, UCLA
10:30am PathFinder: A Negotiation-Based Performance-
Driven Router for FPGAs, L.E. McMurchie,
C. Ebeling, U. Washington
10:50am Applications of Slack Neighborhood Graphs to
Timing Driven Optimization Problems In
FPGAs, A. Mathur, K.C. Chen, C.L. Liu,
U. Illinois, Fujitsu America, San Jose
11:10am Testing of Uncustomized Segmented Channel
Field Programmable Gate Arrays, T. Liu,
W.K. Huang, F. Lombardi, Texas A&M University
Posters: Routing and Fault-Tolerance 11:30-12
LUNCH 12:00 - 1:30
Session 7: Multi-FPGA Partitioning
Chair: Martine Schlag, UCSC
1:30pm Spectral-Based Multi-Way FPGA Partitioning,
P.K. Chan, M.D.F. Schlag, J.Y. Zien, U. of
California, Santa Cruz
1:50pm Multi-Way System Partitioning into Single or
Multiple Type FPGAs, D. J-H. Huang, A.B.
Kahng, UCLA
2:10pm Multiple FPGA Partitioning with Performance
Optimization, K. Roy-Neogi, C. Sechen, U.
Washington
2:30-3:30pm Coffee & Posters
Session 8: Applications and Bit-Serial Synthesis
Chair: Sinan Kaptanoglu, Actel
3:30pm Techniques for FPGA Implementation of Video
Compression Systems, B. Schoner, J. Villasenor,
S. Molloy, R. Jain, UCLA.
3:50pm An SBus Monitor Board, H.A. Xie, K.E.
Forward, K.M. Adams, D. Leask, U. Melbourne,
Australia
4:10pm High-Level Bit-Serial Datapath Synthesis for
Multi-FPGA Systems, T. Isshiki, W. W-M. Dai,
U. California, Santa Cruz
Posters: Applications 4:30-5:00
FPGA `95 REGISTRATION
---------------------
The Symposium registration fee includes a copy of the symposium proceedings,
a reception on Sunday evening, February 12, coffee breaks, continental breakfast
on the first day, lunch on both days, and dinner Monday evening, February 13.
First Name:___________________________________________
Last Name:____________________________________________
Company/Institution___________________________________
Address:______________________________________________
City:___________________State:_____________
Postal Code:_______________Country:____________
Email:________________________________________
Phone:_______________________Fax:_______________________
Circle Fee Before January 25, 1995 After January 25, 1995 ACM Member #____________
ACM/SIGDA Member US $320 US $390
*Non-Member US $417 US $487
*If you are not an ACM/SIGDA member we are giving you the opportunity to
join by paying your first year's dues out of your conference non-member
registration fee -- a US$97 value. Forms will be available at on-site
registration.
Guest Reception Tickets #Tickets______x US $15 ______
Guest Banquet Tickets #Tickets______x US $40 ______
Total Fees:____________________(Make checks payable to ACM/FPGA'95)
Payment Form (Circle Once)
AMEX MASTERCARD VISA CHECK
Credit Card#:_____________________
Exp. Date:________________________
Signature:________________________________________
Send Registration with payment to:
FPGA `95, Colleen Matteis, 553 Monroe St., Santa Clara, CA. 95050, USA.
Phone: +1(408)296-6883 Fax: +1(408)296-5452.
For registration information contact Colleen Matteis,
e-mail: sigda@nextwave.com. Cancellation must be in writing, and
received by Colleen Matteis before January 24,1995.
Hotel Information
-----------------
The symposium will be held at the Monterey Marriott, 350
Calle Principal, Monterey, CA 93940, USA. The phone
number for room reservations is (408) 649-4234.
Reservations must be made directly with the Hotel before
January 20, 1995. Identify yourself with the group
Association for Computing Machinery FPGA `95
Symposium to receive the special Symposium rates,which
are $110 for single or double occupancy; parking is $10 per day.
Check-in time is 3pm.
Directions to Hotel: From San Jose (a 1.5 hour trip), take
HWY 101 South to HWY 156 west to HWY 1 South. On
HWY 1 South, take the first exit in the city of Monterey
(labelled Del Monte Ave.). Continue on Del Monte Avenue
until the tenth traffic light. Stay in the left lane, and the
hotel will be on the left. The hotel is the tallest building in
the City of Monterey.
You can also fly directly to the Monterey Airport, which
handles United, American and other air lines with at least
8 flights per day.
Article: 489In <3bfpbu$tdu@hearst.cac.psu.edu> SANJAYB@ECLX.PSU.EDU (Sanjay Balasubramanian) writes: >Hi, > We are currently using the XC3090PG175 to implement a circit which >demands a speed of 25MHz (40ns). However any attempt to reach a speed higher >than 12ns has proved futile with the XC3090. (We are only using 38 CLBs and >abot 70 I/O pads, 150 speed grade). Are there existing designs which run at >higher speeds on the XC3090 and if so any pointers to increase the performance >will be greatly appreciated. >Please e-mail us at: >s1b@eclu.psu.edu >Center for Electronic Design, Communication and Computing >University Park. >Thanks in advance, >Sanjay B. > You don't mention what sort of circuit you are trying to implement. I have some limited experience with the part you are using and perhaps some of this may apply. If you are trying to do stuff that requires wide gating functions - multi-bit counters, adders, etc. then the limited number of inputs per CLB really becomes problem with the XILINX architecture. Several CLBs must be used serially to get the desired function and therefore much speed is lost. I have also found that using the library functions is very simple but almost always results in a slow design. It seems that you really need to get in and work at the CLB level. The XACT tool seems to do a horrible job at CLB placement considering how long it takes to do it. Perhaps it is designed to optomize for resource usage rather than speed. (or perhaps I just don't know how to use it.) Anyways, I found that I could get tremendous speed increases by doing my own CLB placement and optomizing critical signal interconnection through the direct interconnects. I was able to achieve a 20-bit 20Mhz counter on a 125Mhz part using this approach, but it took a lot of work. A bonus in doing your own placement is that the compiler runs much faster. Has anyone else had similar experience or can suggest ways to use the compiler to optimize more for speed?Article: 490
We are currently working on a large design including digital filters, shift registers, SRAM's, VRAM's, etc. Also we will be using FPGA's to handle timing, control and ALU functions. We are looking for CAD tools for overall design description and simulation and FPGA synthesis. So far we have looked at Data I/O's Synario, Viewlogic's Pro Series, Exemplar Logic and the Xilinx development tools. Are there any comments on these systems or on alternatives? ----------------------------------------------------------------- Ryan S. Raz Morphometrix, 120 Adelaide St. E., Unit 2, Toronto, Ontario, Canada M5C 1K9 Tel: (416)361-6239 Fax: (416)361-3162 Email: morph@io.org -----------------------------------------------------------------Article: 491
I need xnf files for Partitioning93 benchmark circuits. The xnf files currently available are in LCANET Version 2, which are not acceptable to the latest XACT tools (version 5.0). I need xnf files in LCANET Version 4 or 5. I tried to use 'xnfcvt' program, but that translates only from higher to lower version, e.g. from 5 or 4 to 2. Any help will be greatly appreciated. KhalidArticle: 492
"Low Cost IC Design Software for the PC" There is a new low cost PC version of L-EDIT "the student edition" for the layout and evaluation of custom CMOS IC designs. Book Review - PHY. DESIGN OF CMOS ICs USING L-EDIT (tm) by Uyemura A new book "PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L-EDIT (1995)" by John P. Uyemura has been published by PWS Publishing Company (Boston, MA). This $54.95 book (ISBN 0-534-94326-8) includes the L-EDIT student edition which provides students and industry professionals a complete tool to learn the art of CMOS integrated circuit design and layout on a standard IBM Compatible PC. For those in the know, L-EDIT is the best kept secret in the IC industry. L-EDIT is the work of industry legend John Tanner and the gurus at Tanner Research. L-EDIT provides a complete VLSI IC Design software environment for a few thousand dollars including custom design, autorouting, DRC, Extraction, LVS and compatible libraries. The new L-EDIT student edition together with Uyemura's book extends Tanner's innovation providing an outstanding tool to learn IC design. "PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L-EDIT" is a well focused and integrated book that teaches elementary digital CMOS design and layout. This 209 page book includes the necessary information in a well organized format, for the engineering student or self study professional with no IC background, to learn elementary IC design. This book condenses the complexity of IC physics, concepts, fabrication processes, design rules, physical implementation and modeling equations into the essentials to understand IC design and layout. The book then proceeds to apply these elements using L-EDIT to create working designs. The book takes the student through the design steps and provides the KEY design data, coefficients, and setups at the right learning point sparing the student the typical confusion from information overload. The book is well integrated with the L-EDIT student edition starting with program setup, and proceeding with cell layout, design rules, DRC, modeling, extraction, and spice modeling. The book is particularly good at linking basic gates and layout style. It also details the more esoteric aspects of layer setups for extraction and DRC and provides the necessary details for spice modeling. The book also includes a first introduction to the varied aspects of digital CMOS design including devices, gates, logic types, and CMOS processes as well as more complex layout design. For the price, the book together with the PC compatible L-EDIT student edition is a bargain including full IC layout, multi-cell hierarchy design, comprehensive design rule check, spice 2/3 compatible IC layout extraction, cross-sectional viewer and technology compatible setups for standard CMOS processes. The user interface and features are the same as the professional level L-EDIT program except for a limit on database size ( suited for up to a "Mosis Tiny"-2.2 mm x 2.2 mm ) and the use of the Tanner TDB format for saving work files. The professional level L-EDIT program is needed to convert from the Tanner TDB file format to the industry standard CIF or GDSII IC mask generation file format. Cell designs created with student edition are fully compatible with the professional version making the student program ideal for independent work on small designs in industrial settings with a standard PC. To enhance the use of this book and L-EDIT it is recommended that you obtain a copy of the L-EDIT demo disk (V5.0) and use the file scmosmin.tdb as an starting point for an operational cell. While the book includes examples of CMOS designs, it only provides limited L-EDIT TDB file examples. Scmosmin.tdb provides some standard cell gate examples and can be used as a template to get the novice student started with designs that work. The student will need to obtain a copy of Spice to simulate their extracted cell designs. Check out the EDN BBS (617-558 4241) Spice files 29103-5 and down load Howard LeFevre's excellent Berkeley Spice 3F3 (386) Dos shareware. I suspect that most who read this book will become hooked on the wonder of CMOS IC design and will thirst for more. A good added text that provides a more comprehensive treatment of CMOS design and takes you to the system level is "Principles of CMOS VLSI Design 2e" by Weste & Eshraghian. In conclusion "PHYSICAL DESIGN OF CMOS INTEGRATED CIRCUITS USING L- EDIT(tm)" is an outstanding text with companion software for anyone wanting to learn CMOS IC design and layout. John Uyemura has distilled the essentials of CMOS design into an easily useable form that will become the standard for training future CMOS designers. Highly recommended. John Cain Power Processing, Inc.Article: 493
Hello, Sorry for the newbie question, but does anyone know if any FPGA manufactures operate a WWW site for product information and literature? (yes, this does soud like a good idea...) Thanks, ChrisArticle: 494
Hello:
We have designed and built a FPGA-based Computing Machine. Actually, we
do not have any particular application, but just a set of them, and we want
to analyze our architecture and compare it against other approaches.
In the literature, there are certain applications of FCMs described, but
quite usually, they are only overviews.
Our question is:
Is there any set of benchmarks for FCMs to compare different
architectures and software tools?. If so, where it is?
Otherwise, we think it is interesting to open a discussion to set common
benchmarks for FCMs. The benchmarks themselves, the format to express
them (VHDL, verilog, netlists...), and some other technical issues (e.g.
how to compare a system with 256 FPGAs against one with 4) are not trivial
problems. Any ideas?
Regards,
Javier Moran
Electronic Engineering Department
ETS Telecomunicacion.
Technical University of Madrid.
Address: Ciudad Universitaria s/n.
Madrid 28040. Spain.
email: moran@die.upm.es
Article: 495> Subject: New Low Cost IC Design Software L-EDIT SE (PC) > > "Low Cost IC Design Software for the PC" > For those in the know, L-EDIT is the best kept secret in the IC > industry. L-EDIT is the work of industry legend John Tanner and the > gurus at Tanner Research. L-EDIT provides a complete VLSI IC Design > The L-EDIT package is great. I had the chance to meet John Tanner and his gang since they live quite close to me. I used their software to design a full custom crosspoint switch that could hold two configurations at a time, you could use one while loading the other and then flip between them. I had never done a full custom design before and I found it very easy to put together a my own chip. I here Tanner is getting a low cost schematic tool that will support all sorts of FPGAs. > Highly recommended. ditto! About benchmarks. > > Is there any set of benchmarks for FCMs to compare different > architectures and software tools?. If so, where it is? There are no benchmarks for reconfigurable computers. I think we should and try to use existing supercomputer benchmarks. We may deside to do fixed point instead of floating but I think if we want to know our relitive preformance it should be relitive to *some* existing standard. Many of the supercomputer standards are based on fundemental computing bottlenecks and real world problems. > > Otherwise, we think it is interesting to open a discussion to set common > benchmarks for FCMs. The benchmarks themselves, the format to express > them (VHDL, verilog, netlists...), and some other technical issues (e.g. > how to compare a system with 256 FPGAs against one with 4) are not trivial > problems. Any ideas? > > I think the format for any benchmarks should be either 1) pen and paper or 2) C code The idea here is to specify the benchmark at the highest level. In the pen and paper approach the benchmark is pure algorithm. Consisting of a mathematical description of the input data, the algorithm and output data. The C code approach gives the implementor a real example of the behavior of an algorithm. A C benchmark allows the designer to make hardware/software tradeoffs -- if their using a big board they can put the whole algorithm in hardware if they are using a small board they can cut up the program and divide and conqure. I'm against VHDL or netlists because this would make the benchmarks look more like PREP, we would only find out how many gates can a system load at one time. It might be slanted toward fine grained architectures or look-up style FPGAs. If we talk about benchmarks let us go in the direction of benchmarks that can be related to by people outside our foucs as well as inside. Steve CasselmanArticle: 496
cdodge@hermes.zkm.de (Chris Dodge) wrote: > > Hello, > > Sorry for the newbie question, but does anyone know if any FPGA manufactures > operate a WWW site for product information and literature? (yes, this does > soud like a good idea...) > > Thanks, > > Chris Xilinx has one: http://www.xilinx.com/ It doesn't have much information, but it is just at the beginning stages. DelayneArticle: 497
Sorry this is a test. Don't flame me.Article: 498
|>
|> I think the format for any benchmarks should be either
|>
|> 1) pen and paper or
|> 2) C code
|>
|> The idea here is to specify the benchmark at the highest level.
|> In the pen and paper approach the benchmark is pure algorithm.
|> Consisting of a mathematical description of the input data, the
|> algorithm and output data. The C code approach gives the implementor
|> a real example of the behavior of an algorithm.
Why C-code? C-code seems like a poor choice as it only supports
sequential semantics. Thus any algorithm implemented in C will
demonstrated *sequential* behavior. However, the goal is to implement
hardware that is highly concurrent. I don't see where C will be
helpful in this case.
|> A C benchmark allows
|> the designer to make hardware/software tradeoffs -- if their using
|> a big board they can put the whole algorithm in hardware if they
|> are using a small board they can cut up the program and divide and
|> conqure.
I think that C falls flat when it comes to hardware/software tradeoffs.
Again, a C-implementation of an algorithm and a hardware implementation
of an algorithm will likely be quite different for the reasons that
I expressed above. Using C will only complicate the design-space
search for mixed hardware-software solutions.
--
Brad L. Hutchings (801) 378-2667 Assistant Professor
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
Reconfigurable Logic Laboratory
Article: 499I was wondering if anyone has any experience driving a PCI bus from an XC4000 device. PCI has specific I/V characteristics which need to be met and has anybody have any experience meeting these criteria (what output driver configuration is needed?). I was also wondering about the wide edge decoding in the XC4000 device. It looks as though the address to be decoded can only be set at configuration. Is this true? How easy is it to modify the config file to change this address? Is this information available? Thanks
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