Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 5550

Article: 5550
Subject: Re: FPGA power dissipation
From: Alfred Fuchs <alfred.fuchs@siemens.at>
Date: Mon, 24 Feb 1997 09:24:56 -0600
Links: << >>  << T >>  << A >>
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-34113
Article: 5551
Subject: Re: Robust Applications with FPGAs
From: Alfred Fuchs <alfred.fuchs@siemens.at>
Date: Mon, 24 Feb 1997 09:54:58 -0600
Links: << >>  << T >>  << A >>
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-34113
Article: 5552
Subject: Re: Xilinx or Altera?
From: Don Wilkerson <dwtdw@tulsa.oklahoma.net>
Date: Mon, 24 Feb 1997 10:03:55 -0600
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx or Altera?
From: Alfred Fuchs <alfred.fuchs@siemens.at>
Date: Mon, 24 Feb 1997 10:58:00 -0600
Links: << >>  << T >>  << A >>
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
Subject: Re: Q: Xilinx PPR Strategy Tips?
From: david holmes <highgate@best.com>
Date: 24 Feb 1997 18:04:22 GMT
Links: << >>  << T >>  << A >>
> 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 Design
Article: 5555
Subject: Re: State Diagram Tools
From: "Carl H. Scheuermann" <Carl.Scheuermann@informatik.uni-jena.de>
Date: Mon, 24 Feb 1997 19:35:28 +0100
Links: << >>  << T >>  << A >>


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: 5556
Subject: Antifuse Comparisons?
From: bdipert@aol.com (BDipert)
Date: 24 Feb 1997 18:43:58 GMT
Links: << >>  << T >>  << A >>
I'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
Subject: Internal Staffing at Texas Instruments - FPGA w/VHDL
From: jfra@msg.ti.com (Jon Francis)
Date: Mon, 24 Feb 1997 18:47:38 GMT
Links: << >>  << T >>  << A >>
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: 5558
Subject: Does anybody know how defaults work in a State Machine in AHDL ?
From: Jonathan_W_Montag@ccmail.ssd.ray.com (Jonathan Montag)
Date: Mon, 24 Feb 1997 21:17:47 GMT
Links: << >>  << T >>  << A >>
Help,

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
Subject: Xilinx + Orcad + XBlox ????
From: Greg Ansley <gja@ansley.com>
Date: Mon, 24 Feb 1997 16:37:41 -0500
Links: << >>  << T >>  << A >>
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: 5560
Subject: Re: Market share - synthesis tools?
From: eteam@aracnet.com (bob elkind)
Date: Mon, 24 Feb 1997 23:53:32 -0000
Links: << >>  << T >>  << A >>
In 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
Subject: Re: Xilinx or Altera?
From: "Austin Franklin" <#darkroom@ix.netcom.com#>
Date: 25 Feb 1997 00:03:34 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx PPR Strategy Tips?
From: "Austin Franklin" <#darkroom@ix.netcom.com#>
Date: 25 Feb 1997 00:12:09 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 5563
Subject: ISPD-97 Advance Pgm & Registration: (April 14-16, Napa CA)
From: alexande@eecs.wsu.edu (Michael Alexander - EECS)
Date: Tue, 25 Feb 1997 00:32:25 GMT
Links: << >>  << T >>  << A >>
                              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: 5564
Subject: Re: Reverse Engineering FPGAs
From: Eric Dellinger <ericd@xilinx.com>
Date: Mon, 24 Feb 1997 16:42:22 -0800
Links: << >>  << T >>  << A >>
Peter 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
Xilinx
Article: 5565
Subject: Re: Xilinx or Altera?
From: Lance Gin <c43lyg@dso.hac.com>
Date: Mon, 24 Feb 1997 16:52:00 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx or Altera?
From: peter@xilinx.com (Peter Alfke)
Date: Mon, 24 Feb 1997 17:58:32 -0700
Links: << >>  << T >>  << A >>
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 Applications
Article: 5567
Subject: Re: Q: Search Engines for Electronic Parts?
From: maroof@triton.kaifnet.com (Maroof H. Choudhury)
Date: Tue, 25 Feb 1997 02:23:48 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Antifuse Comparisons?
From: Ed Barrett <ed.barrett@postoffice.worldnet.att.net>
Date: Mon, 24 Feb 1997 19:53:47 -0800
Links: << >>  << T >>  << A >>
I don't know about comparisons but one of the major antifuse vendors 
announced that they are exiting the market.
Article: 5569
Subject: Re: How are states changed in ALTERA
From: please@no.junk.mail.com (Mike Williams)
Date: Tue, 25 Feb 1997 04:30:23 GMT
Links: << >>  << T >>  << A >>
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 Solutions
Article: 5570
Subject: Re: Xilinx or Altera?
From: szamos@pacifier.com (szamos)
Date: 25 Feb 1997 05:24:18 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 2nd try: What kind of functions mostly implemented using FPGAs?
From: Ray Andraka <randraka@ids.net>
Date: Tue, 25 Feb 1997 00:57:30 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx or Altera?
From: CoxJA@augustsl.demon.co.uk (Julian Cox)
Date: Tue, 25 Feb 1997 10:58:53 GMT
Links: << >>  << T >>  << A >>
"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 :-)

Julian

Article: 5573
Subject: Re: Xilinx or Altera?
From: Steve Wiseman <steve@sj.co.uk>
Date: Tue, 25 Feb 1997 11:02:59 +0000
Links: << >>  << T >>  << A >>
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.)

  Steve
Article: 5574
Subject: Who's there?
From: Ian <isg100@york.ac.uk>
Date: Tue, 25 Feb 1997 14:49:56 +0000
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search