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
Ray Andraka wrote: > > Peter wrote: > > > > I think that FPGA dynamic Icc is high because of all the "superfluous" > > nets which are toggled, rather than due to any property of the silicon > > process used to make the logic elements.... > > > > You hit the nail on the head. This is why the vendors find it so hard > to put together a simple power calculator. I know Xilinx has > painstakingly measured their devices to characterize the power > consumption of various elements in the FPGA, including clock > distribution, routing, long-lines, I/Os etc. The results of their > research are published in the 1996 databook. Granted, it makes > computation of power kind of a pain in the patoot, but at least when you > do it, you get an accurate result. Others give simpler formulas that > don't seem to take into account all the variables you so aptly > identified. While those simpler formulas may be less scary, I, for one > am not convinced of their accuracy. I guess its just another case of > buyer beware....Now If someone would come up with software that could > take that Xilinx data along with switching info for nodes in the design > (including clock nets and i/o) and spit out accurate power dissipation > numbers. > > -Ray Andraka, P.E. Exactly. I really do not understand, why it should be so difficult. Altera e.g. does publish simple formula to calculate power dissipation based of the number of toggling FFs. It would already be a quite helpful feature to let the user define a representative simulation pattern and let a tool count the transitions. If you do a post-layout simulation, you have all the information together, even if your power dissipation depends strongly on routing paths. What's wrong with my wish? Fuchs Alfred Siemens Austria PSE EZE TNT -- My little grey cells speak for themselves, not for my company. But have a look at http://www.siemens.at, .de or .com mailto:alfred.fuchs@siemens.at; Phone: 43/1/1707-34113Article: 5551
Scott Kroeger wrote: > > sundberg jeffrey r wrote: > > > need to imprelement a cruise control/engine... > >... what is the best target device platform to implement the design on > > Hello Jeff, > > The auto industry has been doing that job in little single chip > microcontrollers for many years. Their environment is far harsher than > yours. The Microchip PIC and National COP-8 family of processors and > tools are available from DigiKey. Motorola's 68HC05 family and the > various flavors of 8051 from many manufacturers may also be suitable. > > If your needs are more sophisticated, I'd check your local Hitachi rep > to see if they still have their $99 SH-1 evaluation board. This gives > you a very capable RISC microcontroller with 128KBytes of external RAM > and some external EPROM, complete with GNU development toolchain, for > $99. > > Regards, > Scott And if you decide to take the best 16-bit µC: Look at the Siemens C166 Family. I am no marketing man, but I know independent surveys - and they say exactly that. Of course this is off topic. In order to save power you absolutely should take SRAM-based FPGAs. Alfred -- My little grey cells speak for themselves, not for my company. But have a look at http://www.siemens.at, .de or .com mailto:alfred.fuchs@siemens.at; Phone: 43/1/1707-34113Article: 5552
I'm trying to choose between Xilinx and Altera. My three main selection
criteria are tool/part availability, power consumption, and design tool
"ease of use".
Does anyone have any actual comparative power consumption data on the
Xilinx 4000L, Xilinx 4000XL, and Altera 10K50V? I have a ~3.3V system
which needs several state machines and data processors. The vast
majority
of the device will probably clock at < 1 MHz. This design must be
finished
without slipping the schedule by more than a couple of hundred
nanoseconds.
I read this comment somewhere:
> Xilinx power consumption is lower, everything else being equal. This is
> the result of the different interconnect structure, and no marketing
> posturing can defy the laws of physics. ( The Altera message that the "sum
> of internal power is proportional to the percentage of blocks toggling at
> the clock rate" is wrong. It's tough to respect people who publish this
> kind of nonsense ).
I'm not sure whether to believe the previous comment. I can believe
that the
interconnect structures consume different amounts of power due to their
differences (routing buffers, parasitic capacitances, etc.). However,
shouldn't the unloaded AC component of power consumption be proportional
to
the switching frequency of the transistors used by the logic and the
transistors used by the routing resources, and the capacitances of the
interconnect within the FPGA??
I wonder how much the following ratio varies between the different
vendors
for different types of application circuits?
ratio = silicon stuff used by logic
-----------------------------------------------------------------
silicon stuff used by logic + silicon stuff used to connect
logic
Article: 5553
Bill Harris wrote:
>
> Stuart,
>
> I use whatever is the best device for the particular design in terms of
> suitability, price, performance, availability, etc.
So do we.
>I have done
> several Xilinx 3K, 4K and 7300 designs (one board had all three
> families on the same board), and more Altera 5K, 7K and 8K designs than
> I care to remember. I have also done a couple of MACH parts and
> a few Lattice designs.
I didn't do Xilinx, but all Altera families and GALs.
>I do have the luxury of having access to all the
> different vendor's tools, which most engineers at small companies do not
> have. I find that the Altera designs are generally the least
> troublesome with the smoothest development flow, but when things go bad,
> the Altera tools don't give you the flexibility to get into the part and
> really tweak it like the Xilinx tools do. Fortunately, those situations
> are few and far between these days.
>
> I recognize marketing hype when I see it, and consider the source when I
> see outrageous claims for any electronic component which are obviously
> not from the engineering group. When I see bad engineering
> recommendations coming from a companies' applications group, it does put
> some doubt in my mind about their products.
>
> Bill Harris
> Cisco Systems
>
> "My opinions are my own and do not necessarily reflect those of my
> employer"
Well said.
I would be interested to hear, how you live with the naming tohuwabohu
in programmable logic.
I am sick & fed up with all the creative geniuses who tell me, how to
think.
Hello, all you REAL engineers! Here is the one and only true
classification of programmable devices:
FPD
/ | \
FPLD FPID FPAD
/ \
FPGA FPLA
Fairly neutral, isn't it?
Cleans up the mind.
I said this earlier, but there seems to be a problem with resonance...
Sorry for the "repost":
"Naming programmable devices is a mess.
I think the basic reason is, that every marketing manager is urged to
invent a new name in order not to be a "me-too" runner.
Unfortunately all the smart engineers do not stand up and insist on
THEIR classification as they always did in other fields.
1. Maybe the FPGA/CPLD war boils down to the fact, that p-term logic
structure does not make sense with fine-grain interconnect. Altera, too,
called their FLEX series FPGAs in early databooks - and found itself
seen as a me-too vendor.
I proposed: PGA vs PLA as two children of PLDs. You can add an F to
every
term if you want. A few people do use FPLD.
2. When are PLDs NC (not complex) or S (simple)? There are various
definitions (Typical for engineering??). I proposed: If there is only
global interconnect, then it's small. Because you will surely never see
a big chip with global interconnect.
3. Presently we can re-view the same story with programmable analog
devices (EPAC, FPAA, FPAD, ...) and programmable interconect devices
(FPIC,
FPID, ...).
4. There is an emerging overall term FPD, which means Field Programmable
Devices, but the abbreviation is associated with Flat Panel Display as
well.
5. Another topic: Are FPGAs/CPLDs ASICs? From their usage pattern many
people tend to say yes. But on the other hand there is nothing
"Application Specific" with them and in fact this is one of their
essential advantages. Actually they are the successors of standard logic
components. Even Xilinx says that.
The rivalry between the FPGA and CPLD camps is nothing but a bid for
domination of engineers minds. Don't let marketing nonsens dominate you!
Instead choose a clear language, a simple formula.
Obviously the professors in the universities do not understand this game
and - like poetry.
I assume that all of you agree."
"Engineers of all countries, unite!" :-)
I appreciate anarchy (=lack of domination) on the net.
Could someone answer to this serious proposal? Clever P. Alfke?
BTW: What about a LCA vs CEPLD infight?
Alfred Fuchs
Siemens Austria PSE EZE TNT
--
My little grey cells speak for themselves, not for my company.
But have a look at http://www.siemens.at, .de or .com
mailto:alfred.fuchs@siemens.at; Phone: +43/1/1707-34113
Article: 5554> We're designing several larger XC4KE devices under XACT 5.2.1 with XABEL as > our HDL (long story; absence of timing-driven mapping is annoying, but not > terminal). Most of the designs are proceeding reasonably. One is giving us > hell. > > We had gotten PPR to produce results that _almost_ met our timing constraints > several times. After complicating the timing constraints to exclude multicycle > paths, and a few design adjustments indicated by functional simulation, the > design now no longer routes. > > We have tried to add placement hints in the form of "bounding boxes" (i.e. > [clb_r1c1 clb_r5c5] kinds of things where the available number of cells in the > box is about twice what is needed), and more carefully placing bussed items, > but PPR is producing more and more unroutes with each run. > > Both placement and routing efforts are maxed. The design used to complete in > about 6 hours, but now seems to want to go for days. As part of trying to > diagnose this problem, we'd been waiting till the ppr.log file indicated > placement was complete and then issuing a kill -2 to review the placement, but > have begun to just set route=false. > > A symptom seems to be that when the solutions were _almost_ meeting timing, > the occupied CLBs reported by Floorplanner seemed to be evenly distributed > across the device (as were the unoccupied CLBs), but now PPR keeps packing the > CLBs in a tight knot near the center of the device, so it runs out of routing > channels. It also used to sequence bus bits pretty well, but now scrambles > them hopelessly (so we now explicitly place key register bits as anchors). > > The hotline suggested that we noplace every third row or so to force better > distribution of CLBs. This sounds like a hack, and we didn't need it before > (nor on the other designs that use timing constraints). Has anyone else seen > this kind of behaviour, or have any PPR or constraint tips that might get us > out of this hole? Can anyone provide a better description of how PPR works, > what it looks for, what it tries, to give us some insight on how to work > around it? Any help is appreciated. > > -- > --------------------------------- > Tom Vrankar > twv@ici.net > http://www.ici.net/customers/twv/ > Rhode Island, USA > In order to route a large design it helps to completely place ALL of the data structures. Also ensure that ABEL is generating one-hot state machines. David Holmes HighGate DesignArticle: 5555
Kevin D. Drucker wrote:
Sorry about the psuedo-spam...
I am looking for a tool to assist me in documenting state machines.
Something similar to Rational Rose (which is a C++ tool), but
specifically geard towards digital logic design. It would be nice
if it
allowed you to show the diagrams either as a mealy or moore type
machine.
Any one know of such a tool? If there is a shareware program out
there
that'd be great. Windoze 95 or HP-UX...
Hi,
I just found a little program called brusey. I don't know if that is
what you are looking for. But maybe it is of help. I attached the
Readme.
cu
Carl
--
Carl H. Scheuermann
LS f. Rechnerarchitektur, Friedrich-Schiller-Univ. Jena
Carl.Scheuermann@uni-jena.de, C.H.Scheuermann@ieee.org
PGP-Public-key: http://www2.informatik.uni-jena.de/~carls/pubkey.asc
>>>>>>>>>>>>> filename="README"
BRUSEY20 - PIC to VHDL Parser - v2.4
Copyright (C) 1997 by Tom Mayo
Brief Description
-----------------
This program is used to translate a state diagram into synthesizable
VHDL. The state diagram may be entered with XFig, a free drawing tool.
The format which brusey20 accepts is the PIC format, which may be
exported by XFig. Output is at least suitable for synthesis using
Exemplar's Galileo. It may also be useful for other synthesizers.
To contact the author: tcmayo@fang.berk.net
Tom Mayo
106 S. Hemlock Ln.
Williamstown, MA 01267
I encourage bug reports and enhancement requests!
License
-------
This program is free software; you can redistribute it and/or modify
it under the terms of version 2 of the GNU General Public License as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Installation for Unix
---------------------
If you retrieved a binary which will run on your platform, simply
move it to a directory in your path, for example, /usr/local/bin.
Binaries are available for Linux, SunOS, and AIX.
The documentation is in the form of a man page, brusey20.1. This
file should be moved to a directory in your manpath, for example,
/usr/local/man/man1.
If you wish to compile a new binary, use one of the makefiles
provided. Modify if necessary, then compile. You need flex,
bison, and gcc, all from the GNU organization (available via
anonymous FTP from prep.ai.mit.edu). You may be able to get it
to compile with other "lex," "yacc," and "cc" equivalents, but
I haven't tried.
Using it
--------
The first step is to draw a state diagram and export it to PIC
format.
Next, run brusey20 to generate behavioral VHDL code.
Finally, run your synthesis program to generate a netlist from
the behavioral VHDL.
Please note that VHDL code output by this program is not subject
to any restrictions and may be used for any purpose deemed fit by
the operator of the program. To be clear with respect to the GNU
General Public License which covers the program itself, the output
of this program is not to be considered a "work derived from the
program".
There are several examples of VHDL styles brusey20 can currently
produce, and what it should be capable of in future revisions.
Currently, the woj, exemplar_a1, and new examples are supported.
They will synthesize with Exemplar's Galileo.
Documentation
-------------
Stinks.
Seriously, my thesis describes the inner workings of brusey20, and
gives some hints on how to draw state diagrams so that brusey20 can
understand them. It is available from my web page:
http:/bcn.net/~mayo
I'm sorry, but I haven't written a user's guide yet.
Revision History
----------------
2.4 - Corrects a problem brought to light by a state machine drawn by
Benoit Payette. The lexical analyzer did not parse negative
numbers. This caused components outside the normal sheet size
to be reflected about X=0 and/or Y=0, and thus to be incorrectly
associated with other components.
2.3 - Adds the capability to use state transition priorities. This is
a very exciting addition which allows use of brusey20 for real-
life designs. To do this, transitions get a number and a colon
prepended to their condition string. Example:
1: a = '1' | b <= '0';
For a full example, see new.fig in the examples/new directory.
Earlier Revisions - I forgot.
--
Tom Mayo N1MU
Article: 5556I'm interested in hearing from those who have evaluated products from antifuse vendors Actel and QuickLogic. How do they compare in terms of power consumption, performance, usable gate count? What about development tool robustness? Any other comments? Thanks in advance. -- Brian Dipert Sacramento, California bdipert@aol.com Visit me at http://members.aol.com/bdipert The mass of men lead lives of quiet desperation -Henry David Thoreau 'Walden'Article: 5557
I am an internal staffing person for the Defense Systems and
Electronics group of Texas Instruments (soon to be part of Raytheon).
I am not a headhunter, but am trying to locate qualified Digital Logic
Designers with VHDL experience.
I thought that the people reading this newsgroup might know of someone
in their "network" who might be interested in this position. If not,
please forgive my intrusion into your newsgroup.
Here is the ad we have been running:
********************************************************************************
Defense Systems and Electronics, Texas Instruments, is proud to be
joining the Raytheon Defense Team.
We currently have an immediate need for the following position at our
Sherman, Texas location.
T I T L E:
********************************************************************************
Senior Digital Logic Designer - FPGA
C L E A R A N C E:
********************************************************************************
Current Secret Clearance required
J O B D E S C R I P T I O N:
********************************************************************************
Senior logic designer to lead a team to develop the next generation of
Paveway III. This person will lead a team of four digital logic
designers.
P R I M A R Y R E S P O N S I B I L I T I E S:
********************************************************************************
Tasks include a dual processor design with FPGA's.
R E Q U I R E D S K I L L S / E X P E R I E N C E:
********************************************************************************
VHDL,Verilog, Synopsys and Autologic experience is required. B.S.
required, M.S. preferred. C programming and Mentor a plus.
Defense Systems and Electronics provides aggressive, performance
-based reward opportunities in addition to the competitive,
comprehensive salary and benefits (including stock options) you would
expect from a world leader in the profitable high tech industry. If
you can meet the challenge of high expectations and are interested in
the opportunity to help define and drive our future successes, Defense
Systems and Electronics is the place for you.
Visit our homepage on the World Wide Web at http://www.ti.com/recruit
D E F E N S E S Y S T E M S A N D E L E C T R O N I C S
Texas Instruments, Inc.
An Equal Opportunity Employer M/F/D/V
********************************************************************************
If interested, contact Jon Francis at jfra@msg.ti.com
Article: 5558Help, We are translating a State Machine from AHDL (Altera's HDL) to XABEL (Xilinx's ABEL). The problem is that in the AHDL file we have, the programmer defaults a set of signals to VCC (the circuit for the most part is active low). The in the first state he sets the signals to be equal to one (no change). Then for the next few states he does not even mention what those signals should be (note: we assume the value of that signal will default to VCC). Then after those few states, he again sets that set of outputs to be equal to one. Therefore we assume the signal never changes state (i.e. always to be VCC), hence there is not real need for the signal to be listed in the states. To give you a little background on this circuit, it has 82 states and it is a symolic state machine (i.e. you list the outputs, not the value of the states). It was written for us and we do not have very good documention on the program. And to make matters worse, we can not get a hold of the original programmer himself. We have downloaded some examples from the net and we have a small handout on AHDL. From those sources, it does seem we are correct on our thinking on the way a symbolic State Machine and the defaults work. But we would like to be sure. Does anybody know for sure ? Also, the programmer seemed to label two states the same name, but gave different values for the output (why did it even compile ?). Though this seems to be a problem, the states to and from the same named states do NOT depend on the inputs. Hence, our thinking, the State Machine will proceed without a problem. Are we right ? We would be forever greatfull for a responce. Thank you for your time, Jonathan Montag Raytheon, RES (SSD)Article: 5559
Question from a (frustrated)newbie to Orcad (but not Xilinx):
Has anybody successfully done a design for Xilinx with XBlox using
Orcad Capture 7.0?
Whose library are you using (Xlinx's or Orcads)?
Whose translation to xnf are you using (Capture's or sdt2xnf)?
Can you successfully get XBlox bus properties across hierarchical block
boundries?
And most importantly where can I find ANY documentation on this that is
accurate?
Any hints or other words of advice welcome...
Thanks in advance,
Greg Ansley gja@ansley.com
Ansley & Associates, Inc. +1 404 248 0827
Atlanta, GA USA
Article: 5560In article <33110411.7579@icd.com.au>, pnibbs@icd.com.au says... > Hi All, > > I would be very greatful if anybody was aware of a site on the WWW where > I could find information on the market share of the major FPGA EDA > vendors - in particular in relation to their synthesis tools. Be careful, Phil... This is a very dynamic market segment right now. The landscape is changing significantly every 6 months, and dramatically every 12 months. New products with attention-getting innovations or price points are popping up with remarkable consistency. (oh yeah, IMHO, lest I forget!) -- Bob **************************************************************** Bob Elkind mailto:eteam@aracnet.com 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: 5561
Julian Cox <CoxJA@augustsl.demon.co.uk> wrote in article <2187cd$b1e36.d9@news.august-systems.co.uk>... > "Iswada Osumundli" <#io@galofzu.net#> wrote: > > >The Lattice parts do not provide enough resources to do a PCI interface, > >except a simple target. If you want burst target or master functionality, > >the Xilinx parts are the only ones that can do it. > > > > IYHBO (In Your Heavily Biassed Opinion) ;-) Julian, I have done 5 PCI interfaces in FPGAs. I also have some pretty good qualifications to make the statements I make, they are not unfounded. If I'm wrong, why not give me some technical data on it, instead of flap. The topic was for a PCI interface. There are things that are certain resources that are required for a PCI interface. I have tried to do a PCI interface in a CPLD (specifically the Altera 7k and the early Plus Logic CPLDs, later bought by Xilinx. I have not tried to do it in the Lattice. If you know that the Lattice can do a PCI interface, enlighten us all, tell us you've done it, and that the parts do have the resources, like CEs in the IOBs, both input and output flops, room for the configuration registers, etc. I only speak from my experience of what I have done and learned what is needed to do a successful PCI interface. Other people may have done it differently, and their experiences differ, and I like to hear those experiences. If you've got some valuable experience to share, please do, if it's just flap, keep it to your self. Austin Franklin ..darkroom@ix.netcom.com.Article: 5562
It would help if you could tell us a bit about the design, like does it have a bus, and if so, how big? Any registers/counters, again how big... Any time you use tri-state busses, and they are larger than a few bits, it is really necessary to hand place them. Also, hand placing the registers etc. will help immensely. Austin Franklin darkroom@ix.netcom.comArticle: 5563
Advance Program
1997 International Symposium on Physical Design
Embassy Suites at Napa Valley, Napa, California
April 14--16, 1997
http://www.cs.virginia.edu/~ispd97/
The International Symposium on Physical Design provides a new and high-quality
forum for the exchange of ideas and results in critical areas related to the
physical design of VLSI systems. The Symposium is an outgrowth of the
ACM/SIGDA Physical Design Workshops held during the years 1987-1996. Its scope
includes all aspects of physical design, from interactions with behavior-
and logic-level synthesis, to back-end performance analysis and verification.
This year's inaugural Symposium focuses on the challenges of high-performance
deep-submicron design, as well as the necessary interactions between physical
design and higher-level synthesis tasks. An outstanding slate of technical
papers has been selected for oral and poster presentation. These developments
are complemented by invited presentations that set forth the contexts and
visions for key areas -- process technology, system architecture, circuit
design and design methodology -- with an emphasis on their implications for
relevant R&D in physical design. The Symposium concludes with a panel of
leading experts who each present their unique perspectives as to the critical
R&D needs of the field.
%%==========================================================================%%
%% Monday, April 14 %%
%%==========================================================================%%
0830-0840 Chairs' Welcome
A. B. Kahng and M. Sarrafzadeh
0840-1010 Keynote Address
* Physical Design: Past and Future, T. C. Hu (UCSD), E. S. Kuh (UCB)
1010-1030 Break
1030-1230 Session 1: Placement and Partitioning
Chairs: D. Hill (Synopsys)
J. Frankle (Aristo Technology)
* Faster Minimization of Linear Wirelength for Top-Down Placement,
C. J. Alpert, T. Chan, D. J. Huang, A. B. Kahng, I. Markov, P. Mulet,
K. Yan (UCLA, Cadence and IBM)
* Network Flow Based Multi-Way Partitioning with Area and Pin Constraints,
H. Liu, D. F. Wong (UT-Austin)
* Partitioning-Based Standard-Cell Global Placement with An Exact Objective,
D. J. Huang, A. B. Kahng (UCLA and Cadence)
* VLSI/PCB Placement with Obstacles Based on Sequence Pair,
H. Murata, K. Fujiyoshi, M. Kaneko (JAIST and Tokyo Inst. of Tech.)
1230--1430 Lunch (Speaker)
* The Quarter Micron Challenge: Integrating Physical and Logic Design
R. Camposano (Synopsys)
1430--1600 Session 2: Synthesis and Layout
Chairs: R. Camposano (Synopsys)
C. Sechen (Washington)
* Timing Driven Placement in Interaction with Netlist Transformations,
G. Stenz, B. R. Riess, B. Rohfleisch, F. M. Johannes (TU-Munich)
* Regular Layout Generation of Logically Optimized Datapaths,
R.X.T. Nijssen, C.A.J. van Eijk (TU-Eindhoven)
* Minimizing Interconnect Energy Through Integrated Low-Power Placement
and Combinational Logic Synthesis,
G. Holt, A. Tyagi (Iowa State)
1600--1630 Break
1630--1830 Session 3: Contexts (Invited)
* Design Technology Trends Based on NTRS Evolution,
P. Verhofstadt, C. D'Angelo (SRC)
* Microprocessor Architecture, Circuit, and Physical Design Trends,
A. Charnas (Sun)
1900--2100 Dinner (Speaker)
* Lithography and Dimensional Trends for Future Processes -- Implications
for Physical Design
P. K. Vasudev (Sematech)
%%==========================================================================%%
%% Tuesday, April 15 %%
%%==========================================================================%%
0830--1000 Session 4: Routing
Chairs: C. L. Liu (Illinois)
D. F. Wong (UT-Austin)
* On Two-Step Routing for FPGAs,
G. G. Lemieux, S. D. Brown, D. Vranesic (Toronto)
* A Simple and Effective Greedy Multilayer Router for MCMs,
Y.-J. Cha (Electronic & Telecomm Research Institute),
C. S. Rim (Sogang U.), K. Nakajima (Maryland)
* Performance Driven Global Routing for Standard Cells,
J. Cong and P. Madden (UCLA)
1000--1030 Break
1030--1200 Session 5: Steiner Tree Constructions
Chairs: M. Marek-Sadowska (UCSB)
N. Sherwani (Intel)
* Min-Cost Flow based Min-Cost Rectilinear Steiner Distance-Preserving
Tree Construction,
J. D. Cho (SungKyunKwan U.)
* Efficient Heuristics for the Minimum Shortest Path Steiner Arborescence
Problem with Applications to VLSI Physical Design,
J. Cong, A. B. Kahng, K.-S. Leung (UCLA and Cadence)
* Provably Good Routing Tree Construction with Multi-Port Terminals,
C. Bateman, C. S. Helvig, G. Robins, A. Zelikovsky (Virginia)
1200--1330 Lunch
1330--1500 Session 6: Back-End Design Methodology
Chairs: E. Yoffa (IBM)
M. Weisel (Intel)
* A Roadmap of CAD Tool Changes for Sub-Micron Interconnect Problems,
L. Scheffer (Cadence)
* C5M - A Control Logic Layout Synthesis System for High-performance
Microprocessors,
J. Burns, J. Feldman (IBM)
* A VLSI Artwork Legalization Technique Based on a New Criterion of
Minimum Layout Perturbation,
F.-L. Heng, Z. Chen, G. E. Tellez (IBM)
1500--1545 Session 7: Poster Presentations
Chairs: G. Robins (Virginia)
J. D. Cho (SungKyunKwan U.)
* A Pseudo-Hierarchical Methodology for High Performance
Microprocessor Design,
A. Bertolet, K. Carpenter, K. Carrig, A. Chu, A. Dean, F. Ferraiolo,
S. Kenyon, D. Phan, J. Petrovick, G. Rodgers, D. Willmott (IBM);
T. Bairley, T. Decker, V. Girardi, Y. Lapid, M. Murphy, P. A. Scott,
R. Weiss (Cadence)
* Concurrent Transistor Sizing and Buffer Insertion by Considering
Cost-Delay Tradeoffs,
J. Kim, C. Bamji (Cadence); Y. Jiang, S. Sapatnekar (Iowa State)
* Towards a New Benchmarking Paradigm in EDA,
N. Kapur, D. Ghosh, F. Brglez (NCSU)
* How Good are Slicing Floorplans?,
F. Y. Young, D. F. Wong (UT-Austin)
* Slicibility of Rectangular Graphs and Floorplan Optimization,
P. DasGupta, S. Sur-kolay (Indian Institute of Management)
* Power Optimization for FPGA Look-Up Tables,
M. J. Alexander (Washington State)
* A Matrix Synthesis Approach to Thermal Placement,
C. Chu, D. F. Wong (UT-Austin)
1545--1715 Session 8: Poster Session
Authors display and discuss one-on-one the posters presented in Poster
Presentation session.
1900--2200 Banquet
%%==========================================================================%%
%% Wednesday, April 16 %%
%%==========================================================================%%
0830--1000 Session 9: Performance Optimization
Chairs: W.-M. Dai (UCSC)
L. Jones (Motorola)
* EWA: Exact Wire Sizing Algorithm,
R. Kay, G. Bucheuv, L. Pileggi (CMU)
* Minimization of Chip Size and Power Consumption of High Speed VLSI Buffers,
D. Zhou, X. Y. Liu, X. L. Wang (UNC-Charlotte)
* Closed Form Solution to Simultaneous Buffer Insertion/Sizing and
Wire Sizing,
C. C. N. Chu, D. F. Wong (UT-Austin)
1000--1030 Break
1030--1230 Session 10: Design Methodology Futures (Invited)
* CHDS: A Foundation for Timing-Driven Physical Design into the 21st Century,
D. Bushroe (Sematech/HP), S. DasGupta (IBM), R. Steele (Sematech/Intel)
* Physical Design 2010: Back to the Future?
A. R. Newton (UCB)
1230--1430 Lunch (Speaker)
* Physical Design Realities for Digital's StrongARM and Alpha Microprocessors
W. J. Grundmann (DEC)
1430--1700 Session 11: Core Directions (or, Do The Right Thing) (Invited)
* Physical Design Challenges of Performance
D. P. LaPotin (IBM Austin Research Lab)
* Panel: Physical Design R&D: What's Missing?
Moderator: G. Smith (Dataquest)
E. Hsieh (Avant!)
M. Hunt (Cadence)
S.-M. Kang (Illinois)
K. Keutzer (Synopsys)
D. P. LaPotin (IBM Austin Research Lab)
N. Sherwani (Intel Hillsboro)
1700 Symposium Closes
%%==========================================================================%%
%% Symposium Organization %%
%%==========================================================================%%
General Chair: A. B. Kahng (UCLA and Cadence)
Past Chair: G. Robins (Virginia)
Steering Committee:
J. P. Cohoon (Virginia),
S. DasGupta (IBM),
S.-M. Kang (Illinois),
B. Preas (Xerox PARC)
Technical Program Chair: M. Sarrafzadeh (Northwestern)
Technical Program Committee:
C.-K. Cheng (UCSD),
W.-M. Dai (UCSC),
J. Frankle (Aristo Technology),
D. D. Hill (Synopsys),
J. A. G. Jess (Eindhoven),
L. Jones (Motorola),
Y.-L. Lin (Tsing Hua),
C. L. Liu (Illinois),
M. Marek-Sadowska (UCSB),
C. Sechen (Washington),
K. Takamizawa (NEC),
M. Wiesel (Intel),
D. F. Wong (UT-Austin),
E. Yoffa (IBM)
Publicity Chair: M. J. Alexander (Washington State)
Local Arrangements Chair: J. Lillis (UCB)
Treasurer: S. B. Souvannavong
Sponsors:
ACM Special Interest Group on Design Automation, in cooperation with
IEEE Circuits and Systems Society
Additional Support From:
Avant! Corporation,
Intel Corporation,
Synopsys Inc., and the
U. S. National Science Foundation.
%%==========================================================================%%
%% Hotel Accommodations and Travel %%
%%==========================================================================%%
ISPD-97 is being held at the Embassy Suites at Napa Valley (formerly the
Inn at Napa Valley) in Napa, California. The hotel is located 55 miles north
of San Francisco, CA in the beautiful Napa Valley. Evans Airport Service
provides daily service between Embassy Suites at Napa Valley and San Francisco
International Airport (SFO) approximately every two hours. On Saturdays and
Sundays, the first departure from SFO is at 8:15am. A one-way fare is $18.00,
and advance reservations are required. Phone 1-707-255-1559 or
FAX 1-707-255-0753. The Embassy Suites at Napa Valley is located at:
1075 California Boulevard
Napa, CA 94559
Phone: 1-707-253-9540
Fax: 1-707-253-9292
Hotel Reservations: 1-800-362-2779
(Central Embassy Suites reservation service.)
A block of rooms is being held for the nights of Sunday through Wednesday
(April 13 through April 16). Room rates are $105 per night for single or
double occupancy. Any individual cancellations within 48 hours from the
date of arrival will be billed for (1) night's stay, plus tax.
+---------------------------------------------------------+
| Please make room reservations directly with the hotel |
| at 1-800-362-2779, mentioning ``GROUP CODE ACM''. |
+---------------------------------------------------------+
The number of rooms available at this rate is limited, and are only being
held through March 14. Early room reservation is highly recommended.
For attendees wishing to stay over Friday and Saturday night, a special rate
of $129 per night, subject to room availablity, has been arranged for
April 11--12 and April 17--19.
%%==========================================================================%%
%% ISPD-97 Advance Registration Form %%
%%==========================================================================%%
Name: _______________________________________________________
Company/University: _________________________________________
Responsibility/Title: _______________________________________
Address: ____________________________________________________
City: _______________________________ State: ________________
Country: ______________________ Postal Code: ________________
Phone: ________________________ Fax: ________________________
Email: ______________________________________________________
Food Choices:
[ ] Vegetarian meals only
[ ] Swordfish or [ ] Filet Mignon (Monday dinner)
Advance Late
(Through March 14) (After March 14)
ACM/IEEE Members [ ] $350 [ ] $425
Non-Members [ ] $425 [ ] $500
Full-Time Students [ ] $175 [ ] $225
Student ID is required if registering as a student.
ACM or IEEE Member No. _____________________________
Registration fee includes meals and Banquet. A limited number of
additional Banquet tickets are available.
_______ Extra Banquet tickets at $50/each.
Payment may be submitted via personal or company check in US funds only and
drawn on a US bank, made payable to ``ACM/1997 International Symposium on
Physical Design''. Payment may also be made with credit card (circle):
Mastercard Visa American Express
Credit Card # _______________________________________________
Expiration Date: ______________ Total Payment: ______________
Name as it appears on credit card: __________________________
Signature: ___________________________ Date: ________________
Please mail or FAX (credit card only) your completed registration form to:
ISPD-97 Symposium Registration
Sally Souvannavong, Treasurer
P.O. Box 395
Pullman, WA 99163-0395
FAX: 1-509-335-3818
Email registration will not be accepted. Cancellations must be in writing
and must be received by March 31, 1997. Questions concerning symposium
registration should be directed to Sally Souvannavong at 1-509-334-3162,
Email: ispd97@eecs.wsu.edu.
%%==========================================================================%%
%% Additional Information %%
%%==========================================================================%%
Check in at Your Convenience:
The symposium registration desk will be open from 4pm to 6pm on Sunday,
April 13th. On Monday, the registration desk will open at 7:30am and
will remain open until 5:00pm.
Experience Springtime in Napa Valley:
Napa Valley weather is very pleasant in April, with an average high temperature
of 78 degrees F and low of 64 degrees F. Attractions include world-famous
wineries offering daily tours, golf and outdoor-recreation facilities, and
easy access to Marine World--Africa USA. Contact the Napa Valley Tourist
Bureau (1-800-523-4353) or Visitors Bureau (1-707-226-7459), or visit the
following websites for additional information:
ISPD-97 Website -- http://www.cs.virginia.edu/~ispd97/
Napa Valley Virtual Visit -- http://www.napavalley.com/cgi-bin/home.o
Conference and Visitors Bureau -- http://www.napavalley.com/nvcvb.html
Driving Directions from East Bay:
Take Hwy 80 to Hwy 37 west, 2 miles to Hwy 29 north, 12 miles to 1st Street
exit to California Boulevard (first left turn off freeway).
Driving Directions from San Francisco:
Take Hwy 101 to Hwy 37 east, 7 miles to Hwy 121 north, then east 15 miles
to Hwy 29 north, 2 miles to 1st Street exit to California Boulevard
(first left turn off freeway).
Article: 5564Peter wrote: (another Peter wrote:) > >Reverse engineering is far more difficult. It is almost impossible to > >deduce the FPGA design from the bitstream. > > Is this not what Neocad must obviously have done? Before Xilinx bought > them, I mean :) No, this is not what NeoCAD did. NeoCAD reverse-engineered the semantics of each bit in each data frame of the bitstream. This allowed us to develop tools to target designs to Xilinx FPGAs. This was an extremely tedious process, and I hope I never have to do it again. This does not, however, provide the ability to divine the designer's original logic, any more than understanding a microprocessor's instruction formats will let you reconstitute C++ code from machine code. Not that it is impossible, but deducing the FPGA design from a reverse-engineered bitstream is equivalent to deducing a program from machine code. You could construct a netlist of CLBs, but without net names, pre-synthesized equation strings, or block names, it would be about as useful as a bunch of assembler code with no variable names or function names. So, SRAM FPGA designs are about as secure as compiled, stripped programs. They are trivial to copy, but it is extremely difficult (if not impossible) to reconstruct semantics. Far less work to just do your own design, rather than rip one off... Eric Dellinger Director, Strategic Software XilinxArticle: 5565
Steve Wiseman wrote: > > Peter Alfke wrote: > > >( that is an obvious result of their simpler interconnect structure), > > Does that somehow demean it? i for one did not interpret peter's comment as demeaning to altera. > environment. What I don't like is _having_ to use them at the lowest > level. I spent 3 weeks trying to get a design working in a 3164a. It was > a couple of k-lines of VHDL. Messing with the layout after each VHDL > change became a nightmare. Perhaps it's an effect of the Xilinx-supplied > VHDL tools, so that all node names change per-compile, and seem to > consist soley of strings of the characters 1, l, i, I, $, 5 and S that > made debugging such a pain, or perhaps I'm only supposed to take the problem created by successive synthesis runs renaming node/instance names, and the resulting impact on downstream tasks such as layout, is unfortunately a common one and not unique to xilinx (xilinx doesn't make the synthesis tools they resell). the renaming itself isn't as bad because most synthesizers will provide an alias list (eg. you started with a schematic or your design is mixed schematic/HDL). a more serious problem, as you point out, is the renaming which varies from synth run to synth run. this makes it almost impossible to perform real incremental layout (for which xilinx has provided options for in their PPR layout tool and which only can be exploited by schematic-only designs). imho, this is a real stumbling block for the development of large HDL-based FPGA's. however, someone within xilinx must be aware of this problem. last year, xilinx worked with synopsys (?) on an incremental place/route tool for their now defunct xc8100 antifuse family. this tool was supposed to be able to match common portions of the previous and new netlists/layouts by comparison based on *topology* as opposed to net names. this is conceptually a really neat idea. sure hope it shows up again sometime (dare i have hopes for M1 ?). obviously, to be effective, the floorplanner would need to support topo comparison as well. > > I hope I did not start a flame. > > Close, very close. gee, i don't think so. then again, i didn't get excited about ucla defeating duke this weekend either ;) -- Lance Gin "Off the keyboard, over the bridge Delco Systems-GM Hughes Electronics through the gateway, C43LYG@dso.hac.com nothing but NET!"Article: 5566
In article <330E99AA.28F@cisco.com>, Bill Harris <wmharris@cisco.com> wrote: > Lets talk about nonsense. Lets look at the Xilinx app note located at > http://www.xilinx.com/partinfo/3volt.pdf > Lets see, on page 6-3 there is a long drawn out explanation of how its okay to drive devices operating at 3.3 volts > with a Xilinx 4000E part operating at 5.0 volts. Lots of really precise language like "nominal", "typical", "track > reasonably". Well, well. This was an attack on the accuracy of my app note about driving 3.3 V devices with our XC4000 outputs, see the Xilinx Data Book, page 6-3/4. That app note was 100% my idea and my writing, so here I am: The explanation is ³long drawn-out² because the issue is complex. The word ³nominally² was only used to demonstrate that it is important to use worst-case rules. I invite everybody to read the analysis. It assumes worst-case conditions. It talks about the possibility of 5 V and 3.3 V supplies "tracking reasonably² , but then analyses the worst case where they do not. And it says clearly that the nominally 5 V supply must not go to 5.5 V when the nominally 3.3 V supply is simultaneously at 3.0 V. I leave it to the designer to draw the proper conclusion. I stand behind this app note. It was meant to show that there is more to an IC than the data sheet numbers. Most manufacturers still claim that input excursions in excess of 0.5 V beyond the supply are dangerous. They are not, as long as the current is limited. After careful investigation and testing, we changed the Xilinx data sheet to allow up to 10 mA forever, and 2 V for a typical reflection of max 20 ns. My app note is carefully phrased and gives the potential user all the information needed to use it, or reject it. This was not written by Marketing. On a different note: My vicious attack at the Altera power specification is based on their erroneous assumption that all internal power is dissipated in logic, and is therefore proportional to the percentage of logic toggling. In reality, the clock distribution dissipates a lot of power, often exceeding the logic dissipation. And clock power does not change with the percentage of logic toggling. The error in the Altera calculation can easily exceed 50%. Of course, it goes without saying that practically all CMOS power is dynamic and therefore proportional to frequency. I enjoy a spirited discussion,as long as it is fair. An applications engineer must be allowed to explain subtleties that go beyond the simple data sheet numbers. We can do that because we are close to the people who designed and test the chips. And some of us have a few decades of experience in systems design. An app note should be written so that everybody can understand the trade-offs involved. Then the reader can make an informed choice to use it or not use it. Yes, I would fly in a plane that uses an XC4000 to drive a nominally 3.3 V input. Why not ! Peter Alfke, Xilinx ApplicationsArticle: 5567
On Thu, 20 Feb 1997 21:59:53 -0500, David R Mulligan <skipper@interlog.com> wrote: >> I'm wondering if there are any internet search engines out there >> exclusively for looking up commercial electronic parts? >> >> I envision an engine that would allow searching by part numbers, >> manufacturers, or functional catagory. Manufacturer and datasheet >> info would be nice. >> >> The only engines I've seen so far are the ones proprietary to >> distributors like Hamilton/Avnet and Marshall. I believe for-fee >> databases are also available (eg. on CDROM) but I'm not sure who >> these companies are. >> >> Thanks in advance, >> >> -- >> >> Lance Gin "Off the keyboard, over the bridge >> Delco Systems-GM Hughes Electronics through the gateway, >> C43LYG@dso.hac.com nothing but NET!" Some of my favorite links to datasheets & search engines: http://www.twinight.org/chipdir/ http://www.sel.sony.com/semi/pdctguid.html http://www.ee.washington.edu/eeca/parts/cross.html http://www.semi.com.tw/Article: 5568
I don't know about comparisons but one of the major antifuse vendors announced that they are exiting the market.Article: 5569
On Mon, 24 Feb 1997 14:19:06 GMT, Yourname@somwhere.COM (Your Name) wrote: >Help, > >We are trying to convert a AHDL file into an ABEL file. The problems that >we have, have to do with the default section of the file and how it is >defined during the state transitions. He defaults a signal to VCC (all of >the circuit was designed to be active low). Then during the first state >he assigns a logic 1 to that signal defined in the default section. Then >for the next few states he does not mention the state of that output, so >we assume the output will take on that default (VCC or unchanged). After >that he will again assign that signal to a logic level 1. From what we >can gather, this signal will never change, hence has no real need to be a >part of this state machine. > >Are we right ? From some of the examples of state machines in AHDL and on >a handout we had on AHDL basics tells us that we are right, but it does >seem strange that the programmer did this. We want to make sure who is >right. The state machine has 82 states, and we don't want to guess. >(Note: We can not get in contact with the orginal programmer) > >Also while I am at it, we have another problem from this same state >machine. Has has named two state the same names, but assigned different >outputs in the two states (i.e. s11 has one set of outputs and s11 has >another set of outputs). I would say this would be a problem, but to get >to and from each of those states has nothing to do with inputs, hence I >would guess this would not effect the status of the state machine. Does >anybody know for sure ? > >Thank you for your time, >Jonathan Montag, SSD Raytheon > I'm interested in helping. E-mail me at: mcw@lightlink.com Mike Williams Digital Design SolutionsArticle: 5570
Iswada Osumundli (#io@galofzu.net#) wrote: : The Lattice parts do not provide enough resources to do a PCI interface, : except a simple target. If you want burst target or master functionality, : the Xilinx parts are the only ones that can do it. I don't want to say who and where, but some people at a very big name manufacturer are using 10k parts for PCI design at full speed. (BTW, I'm not talking about my employer)Article: 5571
Erik de Castro Lopo wrote: > I'd agree with what Robert has to say. FPGAs and CPLD are just means of > replacing 74XX series logic and small PALs (ie Lattice 22v10). > > Unfortunately, this seems to be the thinking of too many engineers out there. The result of this thinking is many missed opportunities to really use the FPGA to it's fullest potential. The structure of any of the FPGAs on the market offers so much flexibility not available in older logic series at significantly lower costs. Add to that the capability of unlimited rapid reconfiguration for the 'SRAM' based devices and you open a whole new exciting world of applications. Some of the applications I've personally used FPGAs for include numerous pipelined DSP systems for radar signal processing, imaging, and video. Several of these are reconfigurable computing applications where parts of the logic are changed according to the immediate need to reduce the hardware requirement. Visit my website to see papers on some of my work. Most of these processors would not have been possible to implement in a single FPGA if I were restricted to 74XX logic functions. My point is that saying FPGAs are just a means of replacing random logic is a gross understatement of their capability. It is sort of like saying a PC is just a big calculator. I think the vendors are slightly at fault for this misconception, because for a long time they insisted on including direct copies of 74XX MSI functions in their macro libraries. Many of these, including the TTL counters, make very poor use of the FPGA resource (the FPGA permits many counter styles, the best of which depends on the specific application). Some of the functions, like the BCD to 7 segment decoder that appears in some libraries (this at one point seemed to be in everyone's) are virtually useless in an FPGA. I am not really sure why the 74XX functions (often named something like 74_xxx) are even included. It would seem the vendors were trying to encourage gathering a board full of random logic into the FPGA. The problem is that TTL design is done with a different set of constraints on the design (namely the designer typically seeks to keep the package count to a minimum, the TTL functions in many cases are limited by the package pin counts, and many times a specific function is not available in a single package). Applying a design built under one set of constraints to an architecture constrained by a different set invariably leads to inefficient use of the resources. Too often, the result is a design that performs very poorly (with respect to the capability of the FPGA)or won't route and a frustrated engineer who thinks the part/tools/vendor sucks. Too often, I have seen designs that won't run much faster than 10 MHz in a part that has no problem doing 40+ with a proper design. Often the poor performance is due to the designer not understanding the architecture or trying to apply a design done for a different technology without modification. Now I'll get down from my soapbox. -Ray Andraka, P.E. Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 mailto:randraka@ids.net http://www.ids.net/~randraka/ The Andraka Consulting Group is a digital hardware design firm specializing in high performance DSP designs in FPGAs. Expertise includes reconfigurable computers, computer arithmetic, and maximum performance/density FPGA design. Visit the website for more info.Article: 5572
"Austin Franklin" <#darkroom@ix.netcom.com#> wrote: >Julian Cox <CoxJA@augustsl.demon.co.uk> wrote in article ><2187cd$b1e36.d9@news.august-systems.co.uk>... >> "Iswada Osumundli" <#io@galofzu.net#> wrote: >> >> >The Lattice parts do not provide enough resources to do a PCI interface, >> >except a simple target. If you want burst target or master >functionality, >> >the Xilinx parts are the only ones that can do it. >> > >> >> IYHBO (In Your Heavily Biassed Opinion) ;-) > >Julian, > >I have done 5 PCI interfaces in FPGAs. I also have some pretty good >qualifications to make the statements I make, they are not unfounded. If >I'm wrong, why not give me some technical data on it, instead of flap. > >The topic was for a PCI interface. There are things that are certain >resources that are required for a PCI interface. I have tried to do a PCI >interface in a CPLD (specifically the Altera 7k and the early Plus Logic >CPLDs, later bought by Xilinx. I have not tried to do it in the Lattice. >If you know that the Lattice can do a PCI interface, enlighten us all, tell >us you've done it, and that the parts do have the resources, like CEs in >the IOBs, both input and output flops, room for the configuration >registers, etc. > >I only speak from my experience of what I have done and learned what is >needed to do a successful PCI interface. Other people may have done it >differently, and their experiences differ, and I like to hear those >experiences. > >If you've got some valuable experience to share, please do, if it's just >flap, keep it to your self. > >Austin Franklin >..darkroom@ix.netcom.com. > Austin / Iswada I have little doubt that your experience of designing PCI interfaces is greater than mine. In fact, PCI design is little more than a hobby for me. FPGA design, however, is not. I do try to share my experiences and offer advice when I think it may be appreciated. I do also try, whenever writing such articles, to give a balanced and unbiased opinion. I have absolutely no grounds on which to state that any particular manufacturers parts can or cannot accommodate a PCI interface. I do know though that Altera recommend Logic Innovations Inc (www.logici.com) for 32 and 64 bit PCI Verilog and VHDL models for PCI Bus Masters for use with Altera parts. Similarly, Actel offer CorePCI macros to do a variety of PCI functions including 33Mhz 0ws 32bit Master on Actel silicon. (www.actel.com/products/pci/pcifaq.html) Are both these manufacturers lying to us? Is the silicon incapable of performing these functions despite their claims? I doubt it. If it is _your experience_ that Xilinx parts are the only ones that you have successfully used for PCI masters then would it have hurt to say so in your original post? Your statement, 'If you want burst target or master functionality, the Xilinx parts are the only ones that can do it.' is, I believe, false. If I have offended you by suggesting that you have a leaning towards Xilinx then I unreservedly apologise. If 'flap' is defined as making wild, unsubstantiated comments, than I am indeed guilty. Just as guilty as you Austin. All of the above is, of course, IMHO :-) JulianArticle: 5573
Lance Gin wrote: > the problem created by successive synthesis runs renaming > node/instance names, and the resulting impact on downstream > tasks such as layout, is unfortunately a common one and not > unique to xilinx (xilinx doesn't make the synthesis tools > they resell). the renaming itself isn't as bad because most > synthesizers will provide an alias list (eg. you started with > a schematic or your design is mixed schematic/HDL). Unfortunately, if I use VHDL as my only method of hierarchy, this is less helpful. In a perfect world, I'd like to use VHDL throughout, to make project control easier. (source control on a schematic, while possible, is not pleasant or terribly helpful). Using VHDL throughout is the only way I've got to simulate the whole design at source level. It also allows me to use exactly the same test benches for source-level as post-fitting timing simulation. > a more > serious problem, as you point out, is the renaming which varies > from synth run to synth run. this makes it almost impossible to > perform real incremental layout (for which xilinx has provided > options for in their PPR layout tool and which only can be > exploited by schematic-only designs). imho, this is a real > stumbling block for the development of large HDL-based FPGA's. Yes, I think this is the fundamental problem. Place&route tools are wonderful for schematic-based designs, but collapse for HDLs. Depressingly, I don't know what the solution to this is. You mention incremental routing, based on circuit shape rather than node names. That's a win, and ought to reduce place&route times, but won't help if I need to go in and rummage round. Perhaps the days of rummaging are gone? Re: me getting a 'little' defensive- > gee, i don't think so. then again, i didn't get excited about > ucla defeating duke this weekend either ;) I don't _intend_ to come across as an axe-wielding nutter. Perhaps less coffee / more sleep is in order.... (plus the smiley for a stressed engineer, perhaps #8¬@ ) Bob Elkind wrote: > The ability of an FPGA to accommodate unanticipated > pinout changes is arguably a very valuable attribute. and Peter Alfke [Xilinx] had written > Xilinx devices tolerate pin-locking better than Altera's, an > obvious result of the different interconnect architecture. I'd never dispute that pin-locking is essential to getting designs out and working (and maintainable...). The point I raised was that I consistently get better pin-locked performance from an Altera 8K device than from an equivalent Xilinx 3K. Naturally, YMMV. (Bob - I occasionally get 2-layer, 6 thou boards turned in 4 hours when I really need to, so 12 hours is, if not relaxed, then not the fastest. Naturally, layout takes longer than 4 hours, but a small patch can often be made very quickly.) SteveArticle: 5574
Hello FPGA community. I'm a researcher at the University of York, UK. I am currently investigating FPGAs since I am considering their use in a new project. I need to hear from people who are using these devices outside of the research environment. I am not interested in using FPGAs as a replacement for random logic circuits, but I am interested in using them as computing devices (with a particular emphasis on dynamic/runtime reconfiguration). If you fall into this category, I would be very gratefull if you could email me. I need to know: 1. the broad area of application, 2. what you judge to be their main advantages/disadvantages. Thanks in advance, - Ian _______________________________________________ Music Technology Group, University of York, UK. Web: http://www.york.ac.uk/~isg100/ _______________________________________________
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